SELECT count(*) c FROM full_view WHERE verified > (DATE (NOW()) - INTERVAL 30 DAY)
Если я запустил этот запрос, он занимает секундную долю секунды, но если я переключу оператор сравнения вокруг него, он берет эоны. Теперь первый способ count = 0 и второй способ count = 120000, но если я просто подсчитаю всю таблицу, которая также занимает микросекунды.MySQL - Почему COUNT с «больше, чем» быстро, но «меньше» занимает навсегда?
Но есть что-то фанки, потому что, если запрос когда-либо заканчивается, он быстро запускается быстрее. MySQL кэширует запрос или что-то в этом роде? Ну, я не хочу зависеть от кешей, чтобы убедиться, что сайт не висит.
Это кажется бессмысленным: если он может быстро подсчитать все, что будет больше, чем определенная дата, почему это должно занять больше времени, чтобы считать противоположное? В любом случае, он должен смотреть всю таблицу прямо? И все, что ему нужно вернуть, - это номер, поэтому пропускная способность не должна быть проблемой.
Объясните по запросу:
1, 'SIMPLE', 'b', 'range', 'updated,verified_index', 'updated', '3', '', 28, 'Using where'`
1, 'SIMPLE', 'l', 'eq_ref', 'PRIMARY', 'PRIMARY', '4', 'xyz_main.b.loc_id', 1, 'Using index'
1, 'SIMPLE', 'f', 'ALL', '', '', '', '', 2214, ''
EDIT:
Это может быть какой-то интерес, я нашел эту информацию, когда я запускаю запрос:
Handler_read_rnd_next:
- 254436689 (whe п делать меньше)
- 2 (для больше)
Key_read_requests: 314393 против 33 (33 является самым большим числом для всех статистике при использовании более)
Handler_read_key: 104303 vs 1
В обход зрения и выполнение запроса непосредственно на главном столе исключается медлительность. Итак, что мне нужно сделать, чтобы ускорить его? Мнение по существу, как это:
SELECT x, y, z, verified FROM table1 LEFT JOIN table2 on tab2_ID = table2.ID LEFT JOIN table3 on tab3_ID = table3.ID
РЕШИТЬ: Фрэнки привели Мои в правильном направлении. Вторая объединенная таблица (таблица компании) была объединена через полное текстовое название компаний. Я только недавно решил добавить целочисленный ключ к этой таблице. Столбец имени должен был быть проиндексирован, но я, возможно, это испортил. В любом случае я все реорганизовал. Я преобразовал внешний ключ в основную таблицу, чтобы соответствовать целочисленному идентификатору таблицы компании, а не полному названию компании. Я повторно проиндексировал эти столбцы в каждой таблице, а затем обновил представление, чтобы отразить новую точку соединения. Теперь он работает мгновенно в обоих направлениях. :) Итак, я думаю, что ключевыми являются ключевые слова. Проблема ушла, но все же, я не чувствую, что мой оригинальный вопрос был действительно решен.
Спасибо за помощь.
Я предполагаю, что «full_view» - это представление, каково его определение? –
Что говорит вам «объяснение плана»? –
full_view содержит основную таблицу (с проверенным столбцом) слева, соединенную с двумя другими таблицами. Главная таблица - это люди, а две другие таблицы объединяются в местоположение и информацию о компании. Это довольно прямолинейно. – Moss