primary key

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. Это какая-то документированная особенность или нет?
 

Romantik

TeaM PHPClub
SELECT COUNT(*) FROM test;
вообще не делает запрос

SELECT COUNT(*) FROM test WHERE id = 50000;
всегда работает быстрей, чем
SELECT COUNT(*) FROM test WHERE id <> 50000;
 

adamant

Новичок
Я самый простейший пример указал. В реальности запрос идет по нескольким условиям (то есть - как таковой запрос все-таки делается везде).
 

ForJest

- свежая кровь
SELECT COUNT(*) FROM test WHERE id <> 50000;
Данный запрос при оценке оптимизатором возвращает более трети записей из таблицы. Соответственно MySQL делает фулскан. Поэтому два запроса будет в этом случае более эффективны, чем один.
 

Falc

Новичок
ForJest
"Индекс применяется для столбцов, которые сравниваются с помощью следующих операторов: =, >, >=, <, <=, BETWEEN и LIKE с префиксом, не содержащим шаблонного символа, такого как something%" (с) Ман

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

adamant

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

Falc

Новичок
ForJest
У меня никакой разницы нету.

-~{}~ 09.08.04 17:30:

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

NOT ( id = 50000 )
 

ForJest

- свежая кровь
Falc
Да. Получается MySQL очень упорно не хочет по <> искать.
 

Falc

Новичок
.des.
Так же тормозит, но эксплаин написал что индексы использует.
 
Сверху