Тестирование оптимизации MySQL "ГДЕ (Х = 0 или Х = 1)" против "ГДЕ Х <2" - PullRequest
Новая
       2

Тестирование оптимизации MySQL "ГДЕ (Х = 0 или Х = 1)" против "ГДЕ Х <2"

3 голосов
/ 09 марта 2011

Есть ли выигрыш в производительности при удалении операторов OR?

Что компилируется быстрее 

SELECT id FROM mytable where (x=0 or x=1)

или 

SELECT id FROM mytable where x<2

Я сам выполнил тест и второйнемного быстрееНО я не уверен, связано ли это с кэшированием, которое происходит, когда я запускаю первую команду.Есть ли хороший способ оценить два конкурирующих запроса без их кэширования и воздействия на другие?

EXPLAIN дает одинаковый результат: 

+----+-------------+---------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table   | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+----+-------------+---------+------+---------------+------+---------+------+---------+-------------+
|  1 | SIMPLE      | mytable | ALL  | NULL          | NULL | NULL    | NULL | 1407715 | Using where |
+----+-------------+---------+------+---------------+------+---------+------+---------+-------------+

Ответы [ 4 ]

2 голосов
/ 09 марта 2011

Использовать SQL_NO_CACHE: 

SELECT SQL_NO_CACHE id FROM mytable where x<2
1 голос
/ 09 марта 2011

Когда вы выполняли тест, выполняли ли вы запрос один раз или тысячу раз? Потому что время одного пробега вообще не актуально. Вы также можете использовать запрос, объясняющий , чтобы помочь вам принять решение.

Кроме того, ваш второй запрос в качестве проблемы, чтобы принять все значения ниже 0, что может вызвать проблемы.

Существует также другая возможность: 

SELECT id FROM mytable WHERE x BETWEEN 0 AND 1

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

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

1 голос
/ 09 марта 2011

Один из самых простых способов оценки запроса - посмотреть на его выполнение с помощью EXPLAIN .

Вы также можете взглянуть на profiling , хотя это нигде не так полезно в большинстве случаев и более ситуативно.

Как оказалось, EXPLAIN показывает, что ваш запрос не использует никакого индекса (в столбце «возможные ключи» указано «NULL»это причудливый способ сказать, что ничего нет.) В вашем случае добавление индекса столбца x кардинально повлияет на его выполнение.

1 голос
/ 09 марта 2011

Я бы сказал, что вы можете получить достаточно приличное сравнение, если будете останавливать и запускать СУБД перед каждым запросом. Возможно, даже стоит выключить весь компьютер между запусками.

Другая возможность состоит в чередовании большего количества образцов. Выполните два запроса A и B в последовательности A,B,A,B,A,B,A,B,A,B и усредните результаты.

Также (хотя я не знаю об MySQL), большинство СУБД имеют объяснитель запросов, который вы должны использовать для проверки такого рода вещей.

Эти два запроса не являются одинаковыми, если, кстати, id может стать отрицательным.

На основании вашего обновления, вывода EXPLAIN, вы получите одинаковый результат для обоих запросов. Это означает, что между ними не должно быть никакой разницы, при прочих равных условиях.

Однако, поскольку нет упоминания об используемом ключе или индексе (или пригодном для использования), у вас почти наверняка нет индекса на x. Если вы добавите это, вы обнаружите, что запрос будет быстрее (это все равно зависит от мощности x, но, как правило, он должен улучшиться).

...