Почему mySQL работает непредсказуемо?

Question

[KarambyG]

Приведу пример: а таблице имеется 800 тыщ строк.
SELECT * FROM `users` WHERE age = 27
SELECT * FROM `users` WHERE age >= 27

Поскольку в поле age ключа нет, то будет происходить перебор ВСЕХ 800 тысяч строк по порядку. EXPLAIN это доказывает.
Но что интересно.
Первый селект: (11269 всего, Запрос занял 0,0024 сек.)
Второй селект: (597449 всего, Запрос занял 0,0003 сек.)

ИТОГ: первый селект выполнился в 8 раз медленнее!
Даже если сделать более сложные запросы, то такая же тема. Недавно делал какойто запрос сложный.
В первом случае (=) запрос занял 0,02 сек., а во втором случае (>=) запрос занял 0,0005 сек.

Почему так происходит? что за мистика?)

Comments

[FanatPHP]

в пхпмуадмине небось экспериментируем?

[galaxy]

что за мистика?)

кеш это

[KarambyG]

FanatPHP, да а где надо?

[KarambyG]

galaxy, тоесть кеш на (=) не работает, а на (>=) работает?)

[FanatPHP]

ну хотя бы тогда выбирать не *, а count(*).
по очевидным причинам

[galaxy]

KarambyG, на первый запрос не работает, а на второй работает

[KarambyG]

FanatPHP, очевидным для тебя. а для меня нет)

[FanatPHP]

очевидным для любого, кто внимательно смотрит на экран

[galaxy]

KarambyG, ты вот видишь на своем экране все 597449 строк?

[Akina]

Ответ простой - это не MySQL работает непредсказуемо, а кто-то предсказывает неверно.

Кэш прогрет? Зависимость от порядка выполнения запросов проверена? Планы совпадают?

[galaxy]

Akina, тут похоже и не кеш, а просто он своим phpmyadmin фетчит первые 30 строк и удивляется

[Akina]

galaxy, может и так. Если в принципе нет индекса, который используется, то да, очень похоже на эффект начального фетча при фуллскане, когда частота обнаружения значений различается. Запрос недетерминированный, сортировки-то нет...