Чи має значення порядок, де пропозиції мають значення в SQL?

Скажімо, у мене є таблиця з назвою PEOPLE3 стовпці ID, LastName, FirstName, жоден із цих стовпців не індексується.
LastNameє більш унікальним і FirstNameменш унікальним.

Якщо я виконую два пошуки:

select * from PEOPLE where FirstName="F" and LastName="L" 
select * from PEOPLE where LastName="L" and FirstName="F"

Моє переконання, що другий швидше, тому що більш унікальний критерій ( LastName) стає першим у whereпункті, і записи будуть ліквідовані ефективніше. Я не думаю, що оптимізатор досить розумний, щоб оптимізувати перший sql.

Чи правильно я розумію?

Ні, цей порядок не має значення (або принаймні: не має значення).

Будь-який гідний оптимізатор запитів розгляне всі частини WHEREпункту і вигадає найефективніший спосіб задоволення цього запиту.

Я знаю, що оптимізатор запитів SQL Server підбере відповідний індекс - незалежно від того, в якому порядку у вас є дві умови. Я припускаю, що інші RDBMS матимуть подібні стратегії.

Важливо, чи є у вас відповідний індекс для цього чи ні!

У випадку з SQL Server, ймовірно, буде використаний індекс, якщо у вас є:

• індекс на (LastName, FirstName)
• індекс на (FirstName, LastName)
• індекс просто (LastName), або просто (FirstName)(або обидва)

З іншого боку - знову ж таки для SQL Server - якщо ви використовуєте SELECT *для захоплення всіх стовпців із таблиці, а таблиця досить мала, то є хороший шанс, що оптимізатор запитів просто виконає сканування таблиці (або кластерного індексу) замість використання індекс (тому що пошук на повній сторінці даних для отримання всіх інших стовпців просто дуже дорого коштує дуже швидко).

Порядок пропозицій WHERE не повинен змінювати базу даних, яка відповідає стандарту SQL. Порядок оцінювання не гарантується в більшості баз даних.

Не думайте, що SQL дбає про порядок. Далі створюється помилка в SQL сервері:

select *
from INFORMATION_SCHEMA.TABLES
where ISNUMERIC(table_name) = 1 and CAST(table_name as int) <> 0

Якщо перша частина цього пункту була виконана спочатку, тоді лише імена числових таблиць будуть видані як цілі числа. Однак це не вдається, наводячи чіткий приклад того, що SQL Server (як і в інших базах даних) не піклується про порядок пропозицій у операторі WHERE.

Проект ANSI SQL 2003 5WD-01-Framework-2003-09.pdf

6.3.3.3 Порядок оцінки правил

...

Якщо пріоритет не визначається форматами або дужками, ефективне оцінювання виразів, як правило, проводиться зліва направо. Однак це залежить від реалізації, чи дійсно вирази оцінюються зліва направо, особливо коли операнди або оператори можуть спричинити підвищення умов або якщо результати виразів можна визначити без повної оцінки всіх частин виразу.

скопійовано звідси

Ні, всі RDBM спершу починаються з аналізу запиту та оптимізації його, переупорядковуючи пункт your where.

Залежно від того, який RDBM ви використовуєте, можна відобразити результат результату аналізу (наприклад, шукайте план пояснення в Oracle, наприклад)

М.

Оригінальна заява про ОП

Я вважаю, що другий швидше, тому що більш унікальний критерій (LastName) виходить на перше місце в пункті "де", і записи будуть ліквідовані більш ефективно. Я не думаю, що оптимізатор> досить розумний, щоб оптимізувати перший sql.

Я думаю, ви плутаєте це з вибором порядку стовпців під час створення індексів, куди ви повинні ставити більш вибіркові стовпці спочатку, ніж другі, найбільш селективні тощо.

BTW, для вищезгаданих двох запитів оптимізатор сервера SQL не буде робити жодної оптимізації, але буде використовувати план Trivila до тих пір, поки загальна вартість плану буде меншою, ніж порогова вартість паралелізму.

Це правда, наскільки це йдеться, якщо вважати, що імена не індексуються. Однак різні дані помиляються. Для того, щоб з'ясувати, яким способом це зробити, який може відрізнятись кожен раз, СУБД повинна буде запустити окремий запит підрахунку для кожного стовпця та порівняти числа, що коштуватиме більше, ніж просто знизати плечима та почати з цим.