Описывает ли порядок предложений в SQL?

Скажем, у меня есть таблица под названием PEOPLE, имеющая 3 столбца ID, LastName, FirstName, ни один из этих столбцов не индексируется.
LastName является более уникальным, а FirstName менее уникальным.

Если я выполняю 2 поиска:

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

Я считаю, что второе - быстрее, потому что более уникальный критерий (LastName) на первом месте в предложении where, и записи будут устранены более эффективно. Я не думаю, что оптимизатор достаточно умен, чтобы оптимизировать первый sql.

Правильно ли я понимаю?

Ответ 1

Нет, этот порядок не имеет значения (или, по крайней мере: не имеет значения).

Любой надежный оптимизатор запросов будет смотреть на все части предложения WHERE и выяснить наиболее эффективный способ удовлетворить этот запрос.

Я знаю, что оптимизатор запросов SQL Server выберет подходящий индекс - независимо от того, в каком порядке у вас есть два условия. Я полагаю, что другие РСУБД будут иметь аналогичные стратегии.

Что имеет значение, есть ли у вас подходящий индекс для этого!

В случае SQL Server он, скорее всего, будет использовать индекс, если у вас есть:

индекс на (LastName, FirstName)
индекс на (FirstName, LastName)
индекс только (LastName) или просто (FirstName) (или оба)

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

Ответ 2

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

Не думайте, что SQL заботится о заказе. В SQL Server генерируется ошибка:

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

Если первая часть этого предложения была выполнена первой, то только числовые имена таблиц будут отлиты как целые числа. Тем не менее, он терпит неудачу, предоставляя ясный пример того, что SQL Server (как и в других базах данных) не заботится о порядке предложений в инструкции WHERE.

Ответ 3

ANSI SQL Draft 2003 5WD-01-Framework-2003-09.pdf

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

...

Если приоритет не определяется форматами или скобками, эффективная оценка выражений обычно выполняется слева направо. Тем не менее, зависит от реализации, независимо от того, действительно ли выражения оцениваются слева направо, особенно когда операнды или операторы могут создавать условия или если результаты выражений могут быть определены без полной оценки всех частей выражения.

скопирован из here

Ответ 4

Нет, все RDBM сначала начинают, анализируя запрос и оптимизируя его, переупорядочивая предложение where.

В зависимости от того, какой RDBM, который вы используете, может отображать то, что является результатом анализа (например, поиск плана объяснения в оракуле)

М.

Ответ 5

Оригинальная инструкция OP

Моя вера - вторая, быстрее, потому что более уникальный критерий (LastName) на первом месте в предложении where, и записи будут устранены более эффективно. Я не думаю, что оптимизатор достаточно умный, чтобы оптимизировать первый sql.

Я предполагаю, что вы сбиваете с толку это, выбирая порядок столбцов при создании индексов, где вам нужно поставить более выборочные столбцы первыми, чем вторыми, наиболее избирательными и т.д.

BTW, для двух вышеупомянутых оптимизаторов SQL-запросов SQL не будет делать никакой оптимизации, но будет использовать план Trivila, если общая стоимость плана меньше пороговой стоимости parallelism.

Ответ 6

Это правда, насколько это возможно, если имена не индексируются. Однако разные данные сделают это неправильным. Чтобы узнать, какой способ сделать это, который может различаться каждый раз, СУБД должен будет запускать отдельный запрос подсчета для каждого столбца и сравнивать числа, которые будут стоить дороже, чем просто пожать плечами и продолжать с ним.