8.2.1 Optimizing SELECT Statements — MySQL 5.7

8.2.1 Оптимизация операторов SELECT

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

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

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

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

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

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