MySQL FLUSH Команды: Полное Руководство для Администраторов Баз Данных

Оператор `FLUSH` в MySQL заставляет сервер перезагружать внутренние кэши, закрывать и повторно открывать файлы журналов, сбрасывать счётчики состояния и синхронизировать состояние в памяти с дисковыми структурами — всё это без перезапуска сервера. Это делает его одним из наиболее критически важных семейств команд, доступных администратору базы данных.

Знание каждого варианта, его точной области действия и побочных эффектов является обязательным для производственных сред. Например, неправильное использование `FLUSH TABLES WITH READ LOCK` на загруженной OLTP-системе может вызвать общесистемные задержки записи продолжительностью в несколько минут. Этот справочник охватывает все значимые варианты `FLUSH`, включая различия в поведении между MySQL 5.7 и 8.x, особенности InnoDB, риски репликации и требования к привилегиям.

Почему команды FLUSH важны в производственной среде

Сервер MySQL поддерживает множество структур в памяти для ускорения операций: кэш подключений хостов, кэши таблиц привилегий, дескрипторы открытых таблиц, кэши результатов запросов и буферные пулы движков хранения. Эти кэши являются авторитетными во время выполнения. Когда администратор вносит изменения в обход стандартных механизмов — редактируя таблицы привилегий напрямую с помощью `INSERT`/`UPDATE`, ротируя файлы журналов на уровне ОС или перемещая файлы `.ibd` — представление сервера в памяти устаревает. Команды `FLUSH` устраняют это расхождение.

Ключевые операционные категории, где `FLUSH` незаменим:

• Распространение привилегий без перезапуска `mysqld`
• Согласованные онлайн-резервные копии с использованием снимков на основе блокировок
• Ротация журналов в интеграции с `logrotate` или пользовательскими скриптами
• Сброс базовых показателей производительности перед бенчмаркингом
• Инвалидация кэша хостов после изменений сетевой топологии
• Принудительное обеспечение надёжности движка хранения перед окнами обслуживания

Необходимые привилегии

Большинство вариантов `FLUSH` требуют привилегии `RELOAD`. `FLUSH TABLES WITH READ LOCK` дополнительно требует `LOCK TABLES`. В MySQL 8.0+ были введены детализированные динамические привилегии (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`), обеспечивающие более гранулярное управление доступом без предоставления широкой привилегии `RELOAD`. При назначении этих привилегий приложениям или учётным записям мониторинга всегда применяйте принцип наименьших привилегий.

Полный справочник: команды MySQL FLUSH

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Эта команда перезагружает таблицы привилегий в памяти из системной базы данных `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). Сервер считывает эти таблицы при запуске и кэширует их. Любые прямые DML-операции (`INSERT`, `UPDATE`, `DELETE`) с этими таблицами обходят стандартный механизм `GRANT`/`REVOKE`, оставляя кэш устаревшим до выполнения `FLUSH PRIVILEGES`.

Когда использовать:

• После ручного редактирования таблиц привилегий с помощью обычного SQL вместо операторов `GRANT`/`REVOKE`
• После импорта mysqldump, включающего прямые вставки в `mysql.user`
• После восстановления частичной резервной копии схемы `mysql`

Важный нюанс: При использовании операторов `GRANT`, `REVOKE`, `CREATE USER` или `DROP USER` MySQL автоматически перезагружает таблицы привилегий. `FLUSH PRIVILEGES` необходим только при полном обходе этих операторов. Выполнение этой команды без необходимости безвредно, но добавляет кратковременную блокировку кэша таблиц привилегий.

Примечание о репликации: `FLUSH PRIVILEGES` записывается в бинарный журнал и по умолчанию реплицируется на реплики. Как правило, это желаемое поведение при управлении пользователями в топологии репликации.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Эта команда закрывает все текущие открытые дескрипторы файлов таблиц и удаляет их из кэша определений таблиц (TDC). При следующем обращении MySQL повторно открывает файлы таблиц с диска. Это необходимо после любых манипуляций с файлами в обход стандартных механизмов.

Когда использовать:

• После копирования или замены файлов `.frm`, `.ibd` или `.MYD`/`.MYI` на уровне ОС
• Для освобождения памяти кэша таблиц на серверах с очень большим значением `table_open_cache`
• В качестве предварительного условия перед использованием `IMPORT TABLESPACE` в операциях с переносимыми табличными пространствами InnoDB

Соображения о производительности: На сервере с тысячами открытых таблиц `FLUSH TABLES` ненадолго захватывает глобальную блокировку. В высоконагруженных системах это может вызвать заметный всплеск задержки. Для минимизации воздействия предпочтительнее использовать форму с указанием конкретной таблицы (`FLUSH TABLES tbl1, tbl2`).

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Это один из наиболее мощных и потенциально разрушительных вариантов `FLUSH`. Он закрывает все открытые таблицы, сбрасывает кэш запросов и захватывает глобальную блокировку чтения, предотвращающую любые операции записи во всех базах данных. Блокировка сохраняется до выполнения `UNLOCK TABLES` или завершения сессии.

Когда использовать:

• Перед созданием физической резервной копии с помощью таких инструментов, как `mysqldump –single-transaction` (для баз данных только с InnoDB это не нужно — см. ниже)
• Перед использованием `mysqlpump` или `xtrabackup` в средах без InnoDB
• Для создания согласованного снимка на определённый момент времени при использовании смешанных движков хранения (InnoDB + MyISAM)

Критическая ошибка — базы данных только с InnoDB: Для баз данных, использующих исключительно таблицы InnoDB, `FTWRL` почти никогда не нужен. `mysqldump –single-transaction` открывает транзакцию с повторяемым чтением, обеспечивающую согласованный снимок без блокировки записи. Использование `FTWRL` в этом сценарии вызывает ненужные задержки записи.

Риск репликации: Если `FTWRL` выполняется на реплике, это блокирует поток применения SQL, вызывая накопление отставания репликации на время действия блокировки. Всегда отслеживайте `Seconds_Behind_Master` после снятия блокировки.

Взаимодействие с блокировками метаданных: В MySQL 5.7+ `FTWRL` ожидает завершения всех активных транзакций перед захватом глобальной блокировки. На загруженном сервере с долго выполняющимися транзакциями это ожидание может быть бесконечным. Используйте `SHOW PROCESSLIST` для выявления блокирующих транзакций перед выполнением `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL ведёт кэш хостов, в котором записывается история попыток подключения, включая количество неудачных аутентификаций. Когда хост накапливает более `max_connect_errors` последовательных неудачных подключений, MySQL блокирует все последующие подключения с этого хоста до очистки записи кэша.

Когда использовать:

• Когда легитимный хост клиента заблокирован из-за превышения `max_connect_errors`
• После устранения сетевой проблемы, вызвавшей повторяющиеся сбои TCP-подключений
• После изменения DNS-записей, влияющих на то, как сервер разрешает имена хостов клиентов

Альтернатива в MySQL 8.0: В MySQL 8.0+ можно также напрямую усечь таблицу кэша хостов:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Это даёт тот же результат и более прозрачно в автоматизированных скриптах.

Проактивная настройка: Вместо реактивного использования `FLUSH HOSTS` установите `max_connect_errors` на более высокое значение (например, `10000`) или задайте `host_cache_size = 0` для полного отключения кэша хостов в доверенных внутренних сетях.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Сбрасывает большинство переменных состояния сессии и глобального состояния до нуля. Это включает счётчики, такие как `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` и сотни других, доступных через `SHOW STATUS` или `performance_schema`.

Когда использовать:

• Непосредственно перед контролируемым бенчмарком для установки чистой базовой линии измерений
• После изменения конфигурации (например, настройки `innodb_buffer_pool_size`) для изоляции влияния на метрики ввода-вывода
• При написании скриптов тестирования производительности, сравнивающих дельты счётчиков до и после изменений

Важное ограничение: `FLUSH STATUS` не сбрасывает все счётчики. Такие переменные, как `Uptime`, `Uptime_since_flush_status` и некоторые внутренние метрики InnoDB, не затрагиваются. Для комплексного мониторинга используйте таблицы `performance_schema` напрямую — они предлагают детализацию по потокам и событиям, которую `FLUSH STATUS` обеспечить не может.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` закрывает и повторно открывает все файлы журналов сервера. В MySQL 5.7.2+ появилась возможность сбрасывать отдельные типы журналов, что значительно предпочтительнее в производственной среде.

Когда использовать:

• В качестве скрипта post-rotate для `logrotate`, чтобы сигнализировать MySQL об открытии нового файла журнала после ротации старого
• Для принудительного создания нового файла бинарного журнала (эквивалент `FLUSH BINARY LOGS`), что увеличивает порядковый номер бинарного журнала
• Перед архивированием старых журналов для обеспечения записи всех ожидающих данных на диск

Особенности бинарного журнала: `FLUSH BINARY LOGS` создаёт новый файл бинарного журнала и записывает `Rotate_event` в старый файл. Это правильный способ сегментирования бинарных журналов для архивирования при восстановлении на определённый момент времени (PITR). Текущий файл бинарного журнала и позицию можно подтвердить с помощью `SHOW MASTER STATUS` (MySQL 5.7) или `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Пример интеграции с logrotate:

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

Предупреждение об устаревании: Кэш запросов MySQL был объявлен устаревшим в MySQL 5.7.20 и полностью удалён в MySQL 8.0. Если вы используете MySQL 8.0 или более позднюю версию, эта команда не существует.

Для сред MySQL 5.6/5.7, где кэш запросов ещё активен:

• `FLUSH QUERY CACHE` дефрагментирует память кэша запросов без удаления кэшированных результатов
• `RESET QUERY CACHE` полностью удаляет все кэшированные результаты запросов

Когда использовать (только MySQL 5.6/5.7):

• После масштабного пакетного изменения данных, инвалидирующего значительную часть кэшированных результатов
• Когда `Qcache_free_blocks` высок относительно `Qcache_total_blocks`, что указывает на фрагментацию
• Перед отключением кэша запросов (`SET GLOBAL query_cache_size = 0`) для чистого освобождения памяти

Современная альтернатива: В MySQL 8.0+ используйте прогрев буферного пула InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) и `performance_schema` для анализа на уровне запросов.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Сбрасывает счётчики ресурсов для каждого пользователя, отслеживаемые встроенным механизмом ограничения скорости MySQL. Эти счётчики применяют ограничения, определённые в операторах `CREATE USER` или `GRANT`:

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

Когда использовать:

• Когда пользователь исчерпал часовую квоту запросов и ему необходимо немедленно восстановить доступ до естественного сброса счётчика в начале следующего часа
• После увеличения лимитов ресурсов пользователя для немедленного вступления новых лимитов в силу
• В процессе разработки и тестирования для сброса квот между тестовыми запусками

Примечание: Эта команда сбрасывает счётчики для всех пользователей одновременно. На уровне `FLUSH` нет детализации по отдельным пользователям. Если необходимо сбросить счётчики конкретного пользователя, единственный вариант — изменить его учётную запись с помощью `ALTER USER` и затем выполнить `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Принудительно сбрасывает ожидающие буферы записи всех движков хранения в соответствующие файлы журналов. Для InnoDB это означает сброс буфера журнала повторного выполнения (`innodb_log_buffer_size`) в файлы журнала повторного выполнения InnoDB на диске.

Когда использовать:

• Перед созданием холодной резервной копии файлов данных InnoDB для обеспечения согласованности журнала повторного выполнения
• При устранении неполадок движка хранения для исключения несоответствий данных, связанных с буфером
• В рамках предварительного контрольного списка перед остановкой службы MySQL

Контекст надёжности InnoDB: Параметр `innodb_flush_log_at_trx_commit` в InnoDB управляет интенсивностью сброса журнала повторного выполнения при каждой фиксации транзакции. `FLUSH ENGINE LOGS` — это ручное переопределение, принудительно выполняющее сброс независимо от этого параметра. Это полезно в сценариях, где требуется гарантированная контрольная точка надёжности без фиксации транзакции.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Перезагружает файл ключей шифрования DES, указанный параметром запуска сервера `–des-key-file`. Этот файл ключей использовался функциями `DES_ENCRYPT()` и `DES_DECRYPT()`.

Предупреждение об устаревании: Функции `DES_ENCRYPT()` и `DES_DECRYPT()` были объявлены устаревшими в MySQL 5.7.6 и удалены в MySQL 8.0. Поэтому эта команда актуальна только для устаревших установок MySQL 5.6/5.7.

Современная альтернатива шифрования: Используйте встроенное шифрование данных в состоянии покоя MySQL (шифрование табличных пространств InnoDB через `ALTER TABLE … ENCRYPTION='Y'`) в сочетании с плагинами MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) для производственных требований шифрования.

Сравнительная таблица команд FLUSH

Репликация и FLUSH: что реплицируется

Не все команды `FLUSH` реплицируются на серверы-реплики. Понимание этого различия критически важно в топологиях высокой доступности и репликации:

Реплицируется по умолчанию:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (записывается как `Rotate_event` в бинарный журнал)
• `FLUSH USER_RESOURCES`

Не реплицируется (локально для сессии или явно исключено):

• `FLUSH TABLES WITH READ LOCK` — никогда не записывается в бинарный журнал
• `FLUSH STATUS` — влияет только на счётчики локального сервера
• `FLUSH HOSTS` — только локальный кэш хостов
• `FLUSH ENGINE LOGS` — только локальное состояние движка

Чтобы предотвратить репликацию конкретной команды `FLUSH` даже в тех случаях, когда она обычно реплицируется, используйте модификатор `LOCAL` или `NO_WRITE_TO_BINLOG`:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Это полезно при независимом управлении привилегиями на реплике (например, при добавлении пользователей мониторинга, которые не должны существовать на основном сервере).

Автоматизация операций FLUSH с помощью mysqladmin

Многие операции `FLUSH` можно запускать из командной оболочки без открытия клиентской сессии MySQL, что удобно в заданиях cron и скриптах обслуживания:

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

В производственных средах храните учётные данные в `~/.my.cnf` с правами `chmod 600` вместо интерактивной передачи `-p`, или используйте механизм `–login-path` MySQL с `mysql_config_editor`.

Особенности хостинговой среды

Возможность выполнения команд `FLUSH` во многом зависит от хостинговой среды и уровня предоставленного доступа к базе данных. На плане VPS Хостинга у вас, как правило, есть полный root-доступ к экземпляру MySQL, что позволяет выполнять любой вариант `FLUSH`, изменять `my.cnf` и управлять ротацией журналов напрямую. Это минимально рекомендуемая среда для любой серьёзной работы с администрированием баз данных.

На Виртуальном веб-хостинге доступ к базе данных обычно ограничен непривилегированным пользователем без привилегии `RELOAD`, что делает большинство команд `FLUSH` недоступными. Если ваше приложение требует управления привилегиями, контроля ротации журналов или согласованных снимков для резервного копирования, общая среда станет жёстким ограничением.

Для высоконагруженных рабочих нагрузок баз данных — особенно связанных с частыми операциями `FLUSH ENGINE LOGS` или большими буферными пулами InnoDB — Выделенные серверы обеспечивают пропускную способность ввода-вывода и пропускную способность памяти, необходимые для выполнения этих операций без сбоев. `FLUSH TABLES WITH READ LOCK` на сервере с 256 ГБ данных буферного пула занимает заметно больше времени, чем на сервере с быстрым NVMe-хранилищем и выделенными каналами ввода-вывода.

Если вы управляете экземпляром MySQL совместно с веб-панелью управления, VPS с cPanel предоставляет управляемую среду, в которой некоторые операции `FLUSH` (в частности, ротация журналов и перезагрузка привилегий) выполняются автоматически уровнем управления базами данных панели управления, снижая необходимость ручного вмешательства.

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

Контрольный список ключевых выводов

Используйте эту матрицу принятия решений перед выполнением любой команды `FLUSH` в производственной среде:

• Перед `FLUSH TABLES WITH READ LOCK`: Убедитесь, что нет активных долго выполняющихся транзакций (`SHOW PROCESSLIST`). Проверьте, используется ли в вашей базе данных только InnoDB — если да, используйте вместо этого `–single-transaction`.
• Перед `FLUSH PRIVILEGES`: Убедитесь, что вы используете прямые DML-операции с таблицами привилегий. Если вы использовали `GRANT`/`REVOKE`, эта команда избыточна.
• Перед `FLUSH LOGS`: Убедитесь, что ваш скрипт ротации журналов уже переместил/переименовал старый файл журнала перед тем, как сигнализировать MySQL о его повторном открытии.
• Перед `FLUSH HOSTS`: Сначала определите первопричину сбоев подключения. Сброс кэша хостов без устранения основной проблемы приведёт к повторной блокировке хоста.
• В MySQL 8.0+: Удалите все вызовы `FLUSH QUERY CACHE` или `FLUSH DES_KEY_FILE` из скриптов — эти команды не существуют и вызовут ошибки.
• В топологиях репликации: Используйте `FLUSH LOCAL` или `FLUSH NO_WRITE_TO_BINLOG`, когда операция не должна распространяться на реплики.
• Для автоматизации: Используйте команды `mysqladmin flush-*` в скриптах вместо открытия полных клиентских сессий MySQL.
• Аудит привилегий: Для учётных записей мониторинга и резервного копирования предпочитайте динамические привилегии MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES` и др.) вместо широкой привилегии `RELOAD`.

Часто задаваемые вопросы

Нужно ли выполнять FLUSH PRIVILEGES после каждого оператора GRANT или REVOKE?

Нет. `GRANT`, `REVOKE`, `CREATE USER` и `DROP USER` автоматически перезагружают таблицы привилегий в памяти. `FLUSH PRIVILEGES` необходим только после прямых DML-изменений системных таблиц `mysql` (например, `UPDATE mysql.user SET …`).

Может ли FLUSH TABLES WITH READ LOCK вызвать простой приложения?

Да. Эта команда захватывает глобальную блокировку записи, блокирующую все операции `INSERT`, `UPDATE`, `DELETE` и DDL во всех базах данных на сервере. На загруженной OLTP-системе даже несколько секунд `FTWRL` могут исчерпать пулы подключений и вызвать каскадные ошибки приложения. Для баз данных только с InnoDB используйте `mysqldump –single-transaction`, чтобы полностью избежать этого.

Равнозначен ли FLUSH STATUS перезапуску сервера MySQL для целей бенчмаркинга?

Нет. `FLUSH STATUS` сбрасывает большинство счётчиков состояния, но не очищает буферный пул InnoDB, не сбрасывает состояния подключений и не влияет на накопленную статистику `performance_schema`. Для по-настоящему чистого бенчмарка более точным является перезапуск сервера с очисткой буферного пула, хотя это и непрактично в производственной среде.

Почему FLUSH HOSTS отсутствует как самостоятельная команда в некоторой документации MySQL 8.0?

`FLUSH HOSTS` по-прежнему работает в MySQL 8.0, но предпочтительным методом является `TRUNCATE TABLE performance_schema.host_cache`, который более явен и может выполняться без привилегии `RELOAD`, если у пользователя есть `DELETE` для `performance_schema`. Оба метода дают одинаковый результат.

Что произойдёт, если FLUSH ENGINE LOGS выполняется при пиковой нагрузке записи на InnoDB?

Это принудительно выполняет синхронный сброс буфера журнала InnoDB на диск, что может вызвать кратковременную задержку записи при использовании медленного хранилища. На серверах с NVMe-хранилищем воздействие обычно составляет менее миллисекунды. На вращающихся дисках или сильно нагруженном SAN-хранилище это может вызвать заметные всплески задержки. По возможности планируйте эту операцию на периоды низкой нагрузки.