Скажем, у меня есть таблица 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.
Я правильно понимаю?
sql
performance
where-clause
Цзыян Чжан
источник
источник
Ответы:
Нет, этот порядок не имеет значения (или, по крайней мере: не имеет значения).
Любой достойный оптимизатор запросов рассмотрит все части
WHERE
предложения и наиболее эффективный способ удовлетворить этот запрос.Я знаю, что оптимизатор запросов SQL Server выберет подходящий индекс - независимо от того, в каком порядке у вас есть два условия. Я предполагаю, что другие СУБД будут иметь аналогичные стратегии.
Важно то, есть ли у вас для этого подходящий индекс!
В случае с SQL Server он, скорее всего, будет использовать индекс, если у вас есть:
(LastName, FirstName)
(FirstName, LastName)
(LastName)
или только(FirstName)
(или оба)С другой стороны - опять же для SQL Server - если вы используете
SELECT *
для захвата всех столбцов из таблицы, а таблица довольно мала, тогда есть большая вероятность, что оптимизатор запросов просто выполнит сканирование таблицы (или кластерного индекса) вместо использования индекс (потому что поиск на полной странице данных для получения всех остальных столбцов очень быстро становится слишком дорогим).источник
WHERE T1.col_1/T2.col_2 > 10 AND T2.col_2 <> 0
и я получилDIVIDE BY 0
ошибку. После того, как я поменял порядок, условия запрос выполнился успешно. Затем я переключил порядок обратно, чтобы снова получить сообщение об ошибке, но на этот раз это сработало! В конце концов я пришел к выводу, что при первом запуске порядок имеет значение, пока не будет построен план выполнения. После этого порядок не изменится. 'не имеет значения', потому что план оптимизатора / исполнительного директора позаботится об этомПорядок предложений WHERE не должен иметь значения в базе данных, соответствующей стандарту SQL. В большинстве баз данных порядок оценки не гарантируется.
Не думайте, что SQL заботится о порядке. Следующее вызывает ошибку в SQL Server:
Если бы первая часть этого предложения была выполнена первой, то только числовые имена таблиц были бы преобразованы в целые числа. Однако он терпит неудачу, обеспечивая ясный пример того, что SQL Server (как и другие базы данных) не заботится о порядке предложений в инструкции WHERE.
источник
ISNUMERIC(table_name) = 1
был вычислен первым, тоCAST
будет вызываться только для числовых имен таблиц. Но поскольку он не вычисляется первым,CAST
он также оценивается для нечисловых имен таблиц, вызывая сообщение об ошибке.ANSI SQL Draft 2003 5WD-01-Framework-2003-09.pdf
6.3.3.3 Порядок оценки правил
...
Если приоритет не определяется форматами или круглыми скобками, эффективная оценка выражений обычно выполняется слева направо. Однако это зависит от реализации, действительно ли выражения оцениваются слева направо, особенно когда операнды или операторы могут вызывать возникновение условий или если результаты выражений могут быть определены без полной оценки всех частей выражения.
скопировано отсюда
источник
Нет, все RDBM сначала начинают с анализа запроса и его оптимизации, переупорядочивая предложение where.
В зависимости от того, какую RDBM вы используете, может отображать результат анализа (например, поиск плана объяснения в oracle)
М.
источник
Исходное заявление OP
Я предполагаю, что вы путаете это с выбором порядка столбцов при создании индексов, где вы должны ставить более избирательные столбцы на первое место, чем на второе, наиболее избирательное, и так далее.
Кстати, для двух вышеуказанных запросов оптимизатор SQL-сервера не будет выполнять оптимизацию, но будет использовать план Trivila, пока общая стоимость плана меньше пороговой стоимости параллелизма.
источник
Это правда, если предположить, что имена не индексируются. Однако разные данные сделают это неверным. Чтобы выяснить, какой способ сделать это, который может каждый раз отличаться, СУБД должна будет выполнить отдельный запрос подсчета для каждого столбца и сравнить числа, что будет стоить больше, чем просто пожать плечами и продолжить.
источник