Оптимизация "SELECT COUNT(*)..." с помощью предложения Where

Решаемая проблема касается значительно медленного "SELECT COUNT" (*)» в MySQL, даже если применяется предложение «WHERE». Чтобы решить эту проблему, крайне важно понять механизм хранения MySQL.

Кластерные первичные ключи

InnoDB, механизм хранения, используемый в этом случае, использует кластерные первичные ключи. Это означает, что первичный ключ хранится рядом со строкой данных на тех же страницах данных, а не на отдельных страницах индекса. Следовательно, выполнение сканирования диапазона кластерного первичного ключа требует сканирования всех строк, включая их потенциально широкие значения столбцов. В рассматриваемой таблице содержится столбец TEXT, что еще больше усугубляет проблему с производительностью.

Стратегии оптимизации

Чтобы оптимизировать этот запрос, рассмотрите следующие стратегии:

1. Оптимизировать таблицу: Запуск команды «OPTIMIZE TABLE» гарантирует, что страницы данных физически отсортированы по порядку. Эта оптимизация потенциально может повысить производительность сканирования диапазона кластерных первичных ключей.
2. Создайте дополнительный индекс: Рассмотрите возможность создания непервичного индекса исключительно для столбца «change_event_id». Это создаст копию этого столбца на страницах индекса, сканирование которой происходит значительно быстрее по сравнению с кластерным первичным ключом. Проверьте план объяснения после создания индекса, чтобы подтвердить его использование.

Дополнительное предложение

Чтобы еще больше повысить производительность, рассмотрите возможность изменения столбца «change_event_id» на быть «BIGINT UNSIGNED», если он увеличивается с нуля. Это изменение может привести к снижению требований к объему памяти и повышению производительности.