primary key

  • Автор темы Автор темы adamant
  • Дата начала Дата начала

adamant

Новичок
primary key

Столкнулся с одной особенностью при SELECT'ах по полю с индексом PRIMARY KEY при использовании условия "не равно" (<>): запрос вида:
SELECT COUNT(*) FROM test WHERE id <> 50000;

можно просто разбить на два:
SELECT COUNT(*) FROM test;
SELECT COUNT(*) FROM test WHERE id = 50000;

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

MySQL 3.23.58. Это какая-то документированная особенность или нет?
 
SELECT COUNT(*) FROM test;
вообще не делает запрос

SELECT COUNT(*) FROM test WHERE id = 50000;
всегда работает быстрей, чем
SELECT COUNT(*) FROM test WHERE id <> 50000;
 
Я самый простейший пример указал. В реальности запрос идет по нескольким условиям (то есть - как таковой запрос все-таки делается везде).
 
SELECT COUNT(*) FROM test WHERE id <> 50000;
Данный запрос при оценке оптимизатором возвращает более трети записей из таблицы. Соответственно MySQL делает фулскан. Поэтому два запроса будет в этом случае более эффективны, чем один.
 
ForJest
"Индекс применяется для столбцов, которые сравниваются с помощью следующих операторов: =, >, >=, <, <=, BETWEEN и LIKE с префиксом, не содержащим шаблонного символа, такого как something%" (с) Ман

Я думаю оптимизатор даже не пытался оценивать, кол-во выбираемых записей, просто с оператором <> он индексы не использует.
 
ForJest
У меня никакой разницы нету.

-~{}~ 09.08.04 17:30:

adamant
>>Да и результат неправильный получается - 0

NOT ( id = 50000 )
 
Falc
Да. Получается MySQL очень упорно не хочет по <> искать.
 
.des.
Так же тормозит, но эксплаин написал что индексы использует.
 
Сверху