MySQL FLUSH команди: Пълен справочник за администратори на бази данни

Изразът `FLUSH` на MySQL принуждава сървъра да презареди вътрешните кешове, да затвори и отвори отново лог файловете, да нулира броячите на статуса и да синхронизира състоянието в паметта с дисковите структури — всичко това без необходимост от рестартиране на сървъра. Това го прави една от най-критичните от оперативна гледна точка фамилии команди, достъпни за администратор на бази данни.

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

Защо командите FLUSH имат значение в производствена среда

MySQL сървърът поддържа множество структури в паметта за ускоряване на операциите: кеш за хост връзки, кешове на таблиците с привилегии, дескриптори на отворени таблици, кешове на резултати от заявки и буферни пулове на storage engine. Тези кешове са авторитетни по време на изпълнение. Когато администратор прави промени извън обхвата — редактира директно таблиците с привилегии с `INSERT`/`UPDATE`, ротира лог файлове на ниво ОС или премества `.ibd` файлове — изгледът на сървъра в паметта остарява. Командите `FLUSH` съгласуват това разминаване.

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

• Разпространение на привилегии без рестартиране на `mysqld`
• Последователни онлайн резервни копия с помощта на снимки базирани на заключване
• Ротация на логове, интегрирана с `logrotate` или персонализирани скриптове
• Нулиране на базовата линия на производителността преди бенчмаркинг
• Инвалидиране на хост кеша след промени в мрежовата топология
• Прилагане на трайност на storage engine преди прозорци за поддръжка

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

Повечето варианти на `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` в операции с преносими 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
• За създаване на последователна снимка в определен момент от времето при смесени storage engine (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`) за изолиране на ефекта върху I/O метриките
• При скриптиране на тестове за регресия на производителността, сравняващи делти на броячите преди/след

Важно ограничение: `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+ въведе възможността за изчистване на конкретни типове логове поотделно, което е далеч за предпочитане в производствена среда.

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

• Като част от скрипт след ротация на `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;

“`

Принуждава всички storage engine да изчистят своите чакащи буфери за запис в съответните им лог файлове. За InnoDB, това означава изчистване на буфера на redo лога (`innodb_log_buffer_size`) в InnoDB redo лог файловете на диска.

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

• Преди вземане на студено резервно копие на InnoDB файловете с данни за осигуряване на последователност на redo лога
• По време на отстраняване на проблеми с storage engine за изключване на несъответствия в данните, свързани с буфера
• Като част от контролен списък преди поддръжка преди спиране на MySQL услугата

Контекст на трайност на InnoDB: Настройката `innodb_flush_log_at_trx_commit` на InnoDB контролира колко агресивно се изчиства redo логът при всяко потвърждаване на транзакция. `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 tablespace чрез `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` — само локално състояние на engine

За да предотвратите репликирането на конкретна команда `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 — Dedicated сървъри осигуряват необходимата I/O пропускателна способност и честотна лента на паметта, за да направят тези операции ненарушаващи. `FLUSH TABLES WITH READ LOCK` на сървър с 256 GB данни в буферния пул отнема измеримо повече време, отколкото на сървър с бърз NVMe носител и dedicated I/O канали.

Ако управлявате 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 лог буфера на диска, което може да причини кратко спиране на записите, ако redo лог файловете са на бавен носител. На сървъри с NVMe, въздействието обикновено е под милисекунда. На въртящи се дискове или силно натоварено SAN хранилище, може да причини забележими скокове на латентността. Планирайте тази операция по време на прозорци с ниско натоварване, когато е възможно.