10.2.1 Optimizing SELECT Statements — MySQL 9.2

10.2.1 Оптимизация запросов SELECT

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

Помимо операторов SELECT, методы настройки запросов также применяются к таким конструкциям, как CREATE TABLE...AS SELECT, INSERT INTO...SELECT и WHERE-оператор в DELETE-запросах. Эти запросы требуют дополнительных соображений по производительности, поскольку они комбинируют операции записи с ориентированными на чтение операциями запросов.

NDB Cluster поддерживает оптимизацию отложенного объединения, при которой квалифицирующее объединение полностью передается узлам данных NDB Cluster, где оно может быть распределено между ними и выполнено параллельно. Более подробную информацию об этой оптимизации см. в разделе Условия для объединений NDB pushdown.

Основные соображения для оптимизации запросов:

Чтобы ускорить медленный SELECT ... WHERE запрос, в первую очередь проверьте, можно ли добавить индекс. Создайте индексы по столбцам, используемым в условии WHERE, чтобы ускорить оценку, фильтрацию и окончательный возврат результатов. Чтобы избежать неиспользуемого дискового пространства, создайте небольшой набор индексов, которые ускорят многие связанные запросы, используемые в вашем приложении.

Индексы особенно важны для запросов, ссылающихся на разные таблицы, используя такие функции, как и . Вы можете использовать оператор EXPLAIN, чтобы определить, какие индексы используются для запроса SELECT. См. раздел Раздел 10.3.1, «Как MySQL использует индексы» и Раздел 10.8.1, «Оптимизация запросов с помощью EXPLAIN».
Изолируйте и настройте любую часть запроса, например, вызов функции, который занимает чрезмерное время. В зависимости от структуры запроса функция может вызываться один раз для каждой строки в наборе результатов или даже один раз для каждой строки в таблице, значительно увеличивая любую неэффективность.
Минимизируйте количество в ваших запросах, особенно для больших таблиц.
Регулярно обновляйте статистику таблиц, используя оператор ANALYZE TABLE, чтобы оптимизатор имел необходимую информацию для построения эффективного плана выполнения.
Изучите методы настройки, методы индексирования и параметры конфигурации, специфичные для каждого движка хранения для каждой таблицы. Как для InnoDB, так и для MyISAM есть наборы рекомендаций по обеспечению высокой производительности запросов. Подробности см. в Разделе 10.5.6, «Оптимизация запросов InnoDB» и Разделе 10.6.1, «Оптимизация запросов MyISAM».
Можно оптимизировать транзакции с единственным запросом для InnoDB таблиц, используя метод в Разделе 10.5.3, «Оптимизация транзакций только для чтения InnoDB».
Избегайте преобразования запросов в сложные для понимания конструкции, особенно если оптимизатор выполняет некоторые из тех же преобразований автоматически.
Если проблема производительности не решается одним из основных руководств, изучите внутренние подробности конкретного запроса, прочитав план EXPLAIN и скорректировав индексы, WHERE-условия, условия объединения и т. д. (Достигнув определенного уровня мастерства, чтение плана EXPLAIN может стать первым шагом для каждого запроса.)
Настройте размер и свойства областей памяти, используемых MySQL для кэширования. Благодаря эффективному использованию InnoDB, кэша ключей MyISAM и кэша запросов MySQL повторные запросы выполняются быстрее, поскольку результаты извлекаются из памяти во второй и последующие разы.
Даже для запроса, который работает быстро с использованием областей кэш-памяти, можно оптимизировать его далее, чтобы он требовал меньше кэш-памяти, что сделает ваше приложение более масштабируемым. Масштабируемость означает, что ваше приложение может обрабатывать больше одновременных пользователей, более крупные запросы и т. д., не испытывая сильного падения производительности.
Работайте с проблемами блокировки, где скорость вашего запроса может быть затронута другими сессиями, одновременно обращающимися к таблицам.