От перемены мест слогаемых - сумма не меняется

[squirell]

От перемены мест слогаемых - сумма не меняется

Есть два SQL запроса:

1. SELECT * FROM table WHERE Name='name' AND Flag=1;
2. SELECT * FROM table WHERE Flag=1 AND Name='name';

Результат, понятно, будет один и тот же. А вот влияет ли расположение полей в запросе на скорость его выполнения?

 

[vovik]

Нет конечно. Не влияет.

План выполнения запроса строится оптимизатором на основании наличия индексов и статистики, а не на порядке условий в запросе.

 

[MajestiC]

На самом деле влияет. Всё зависит от конкретных данных в БД и самой СУБД. Например если все условия AND, то тогда понятно что если например первое условие не выполняется, то остальные даже нет смысла проверять.

Возьмем пример : есть БД с 100000000 записей имен и их флагов. Предположим, что практически все флаги 0 и очень много повторяющихся имен (Вася, Петя и т.д.). Если нам нужно будет выбрать всех Петь с флагом 1, то запрос вида

SELECT * FROM table WHERE Flag=1 AND Name='Петя'

будет работать быстрее чем

SELECT * FROM table WHERE Name='Петя' AND Flag=1

Так как Петь много, то каждая запись будет сравниваться сначала по имени, и потом еще по флагу. Если же поменять их местами, то сначала будет сравниватся число (что быстрее чем сравнивание строки), и лишь потом имя при совпадении флага с единицей. Если же флаг 0, то имя не будет проверяться, что влечет за собой увеличение скорости выборки на приведенных данных.

PS. Утверждать не могу, так как всё это может различатся в зависимости от данных и самой СУБД.
PPS. Не используя индексов естественно (хоть это и не правильно), так как там совсем другой механизм поиска чем полная переборка =)

 

[voituk]

Точно знаю что в старых версиях MSSQL советовали первыми ставить условия с использованием индексных полей

 

[MajestiC]

Я просто хочу сказать, что в определенных случаях от перемены мест слагаемых сумма меняется =)

А вообще хороших индексов туда, и всё будет ок без всяких перемен.

 

[vovik]

MajestiС

А не затруднит Вас привести ссылку на документацию где это написано или же написать тестовый пример, который подтверждает указанное поведение ?

Что-то мне подсказывает, что написанное не имеет никакого отношения к действительности. Возможно, если бы Вы писали свою СУБД, она работала именно так. Но это не значит, что так делает кто-то еще.

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

В документации на MySQL есть целая глава, называющаяся "How MySQL Optimizes WHERE Clauses".


Резюмирую. Написан бред. Прежде чем что-либо писать настоятельно рекомендую проверить это или хотя бы заручиться поддержкой документации.

 

[MajestiC]

Написано на основе книги SQL Performance Tuning (2002, Peter Gulutzan, Trudy Pelzer. Publisher : Addison Wesley).

Относится не конкретно к MySQL, а к составлению запросов на разных СУБД, на некоторых может повысить скорость.

Еще раз конкретизирую мысль которую я пытался довести : В определенных случаях от перемены мест слагаемых сумма меняется.

Цитата, даже специально отыскал :

When everything else is equal, DBMSs will evaluate a series of ANDed expressions from left to right (except Oracle, which evaluates from right to left when the cost-based optimizer is operating). No rule says they must—that's just what they do. You can take advantage of this behavior by putting the least likely expression first or—if both expressions are equally likely—putting the least complex expression first. Then, if the first expression is false, the DBMS won't bother to evaluate the second expression. So, for example (unless you're using Oracle), you should transform:

... WHERE column1 = 'A' AND column2 = 'B'

to:

... WHERE column2 = 'B' AND column1 = 'A'

GAIN: 6/7 assuming column2 = 'B' is less likely


WARNING

Oracle with the rule-based optimizer shows a gain, but don't do this for Oracle running the cost-based optimizer. The gain shown is for only seven DBMSs.

The gain shown represents an extreme case with this example. In our sample database column2 = 'B' is always false, column1 = 'A' is always true, and there are no indexes. With other scenarios the gain is less and can be 0/8. It's never less than zero though, so reordering ANDed expressions is a highly recommended optimization. Rule-based optimizers will transpose two expressions if they have different point counts.