Polecenia MySQL FLUSH: Kompletny przewodnik dla administratorów baz danych

Instrukcja `FLUSH` MySQL zmusza serwer do ponownego załadowania wewnętrznych pamięci podręcznych, zamknięcia i ponownego otwarcia plików dziennika, zresetowania liczników stanu oraz synchronizacji stanu w pamięci ze strukturami na dysku — bez konieczności restartu serwera. Czyni to ją jedną z najbardziej krytycznych operacyjnie rodzin poleceń dostępnych dla administratora bazy danych.

Znajomość każdego wariantu, jego dokładnego zakresu i efektów ubocznych nie jest opcjonalna w środowiskach produkcyjnych. Niewłaściwe użycie `FLUSH TABLES WITH READ LOCK` w zajętym systemie OLTP może na przykład spowodować ogólnosystemowe przestoje zapisu trwające minutami. Ten przewodnik obejmuje wszystkie istotne warianty `FLUSH`, w tym różnice w zachowaniu między MySQL 5.7 i 8.x, implikacje specyficzne dla InnoDB, zagrożenia związane z replikacją oraz wymagania dotyczące uprawnień.

Dlaczego polecenia FLUSH mają znaczenie w środowisku produkcyjnym

Serwer MySQL utrzymuje liczne struktury w pamięci w celu przyspieszenia operacji: pamięć podręczną połączeń hostów, pamięci podręczne tabel uprawnień, deskryptory otwartych tabel, pamięci podręczne wyników zapytań oraz pule buforów silnika pamięci masowej. Te pamięci podręczne są miarodajne podczas działania. Gdy administrator wprowadza zmiany poza pasmem — edytując tabele uprawnień bezpośrednio za pomocą `INSERT`/`UPDATE`, rotując pliki dziennika na poziomie systemu operacyjnego lub przenosząc pliki `.ibd` — widok serwera w pamięci staje się nieaktualny. Polecenia `FLUSH` eliminują tę rozbieżność.

Kluczowe kategorie operacyjne, w których `FLUSH` jest niezbędny:

• Propagacja uprawnień bez restartu `mysqld`
• Spójne kopie zapasowe online przy użyciu migawek opartych na blokadach
• Rotacja dzienników zintegrowana z `logrotate` lub niestandardowymi skryptami
• Resetowanie punktu odniesienia wydajności przed testami porównawczymi
• Unieważnianie pamięci podręcznej hostów po zmianach topologii sieci
• Wymuszanie trwałości silnika pamięci masowej przed oknami konserwacyjnymi

Wymagane uprawnienia

Większość wariantów `FLUSH` wymaga uprawnienia `RELOAD`. `FLUSH TABLES WITH READ LOCK` dodatkowo wymaga `LOCK TABLES`. W MySQL 8.0+ wprowadzono szczegółowe dynamiczne uprawnienia (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`), umożliwiające bardziej szczegółową kontrolę dostępu bez przyznawania szerokiego uprawnienia `RELOAD`. Zawsze stosuj zasadę najmniejszych uprawnień przy przypisywaniu ich do kont aplikacji lub monitorowania.

Kompletny przewodnik: polecenia MySQL FLUSH

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

To polecenie przeładowuje tabele uprawnień z pamięci podręcznej z bazy danych systemu `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). Serwer odczytuje te tabele podczas uruchamiania i zapisuje je w pamięci podręcznej. Wszelkie bezpośrednie operacje DML (`INSERT`, `UPDATE`, `DELETE`) na tych tabelach omijają normalny mechanizm `GRANT`/`REVOKE`, pozostawiając pamięć podręczną nieaktualną do momentu wykonania `FLUSH PRIVILEGES`.

Kiedy używać:

• Po ręcznej edycji tabel uprawnień za pomocą surowego SQL zamiast instrukcji `GRANT`/`REVOKE`
• Po zaimportowaniu zrzutu mysqldump zawierającego bezpośrednie wstawienia do `mysql.user`
• Po przywróceniu częściowej kopii zapasowej schematu `mysql`

Istotna uwaga: Gdy używasz instrukcji `GRANT`, `REVOKE`, `CREATE USER` lub `DROP USER`, MySQL automatycznie przeładowuje tabele uprawnień. `FLUSH PRIVILEGES` jest konieczny tylko wtedy, gdy całkowicie pomijasz te instrukcje. Uruchamianie go niepotrzebnie jest nieszkodliwe, ale powoduje krótką blokadę pamięci podręcznej tabel uprawnień.

Uwaga dotycząca replikacji: `FLUSH PRIVILEGES` jest zapisywany do dziennika binarnego i domyślnie replikowany do replik. Jest to generalnie pożądane zachowanie podczas zarządzania użytkownikami w topologii replikacji.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

To polecenie zamyka wszystkie aktualnie otwarte deskryptory plików tabel i usuwa je z pamięci podręcznej definicji tabel (TDC). Przy następnym dostępie MySQL ponownie otwiera pliki tabel z dysku. Jest to niezbędne po wszelkich manipulacjach plikami poza pasmem.

Kiedy używać:

• Po skopiowaniu lub zastąpieniu plików `.frm`, `.ibd` lub `.MYD`/`.MYI` na poziomie systemu operacyjnego
• Aby zwolnić pamięć podręczną tabel na serwerach z bardzo dużą wartością `table_open_cache`
• Jako warunek wstępny przed użyciem `IMPORT TABLESPACE` w operacjach przenośnych przestrzeni tabel InnoDB

Uwaga dotycząca wydajności: Na serwerze z tysiącami otwartych tabel `FLUSH TABLES` krótko uzyskuje globalną blokadę. W systemach o wysokiej współbieżności może to spowodować zauważalny skok opóźnień. Preferuj formę specyficzną dla tabeli (`FLUSH TABLES tbl1, tbl2`), aby zminimalizować wpływ.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Jest to jeden z najpotężniejszych i potencjalnie najbardziej destrukcyjnych wariantów `FLUSH`. Zamyka wszystkie otwarte tabele, opróżnia pamięć podręczną zapytań i uzyskuje globalną blokadę odczytu, która uniemożliwia wszelkie operacje zapisu we wszystkich bazach danych. Blokada utrzymuje się do momentu wydania `UNLOCK TABLES` lub zakończenia sesji.

Kiedy używać:

• Przed wykonaniem fizycznej kopii zapasowej za pomocą narzędzi takich jak `mysqldump –single-transaction` (w przypadku baz danych wyłącznie InnoDB jest to zbędne — patrz poniżej)
• Przed użyciem `mysqlpump` lub `xtrabackup` w środowiskach innych niż InnoDB
• Aby utworzyć spójną migawkę punktu w czasie dla mieszanych silników pamięci masowej (InnoDB + MyISAM)

Krytyczna pułapka — bazy danych wyłącznie InnoDB: W przypadku baz danych używających wyłącznie tabel InnoDB `FTWRL` prawie nigdy nie jest konieczny. `mysqldump –single-transaction` otwiera transakcję z powtarzalnym odczytem, która zapewnia spójną migawkę bez blokowania zapisów. Użycie `FTWRL` w tym scenariuszu powoduje niepotrzebne przestoje zapisu.

Zagrożenie replikacją: Jeśli `FTWRL` zostanie wykonany na replice, blokuje wątek aplikatora SQL, powodując narastanie opóźnienia replikacji przez czas trwania blokady. Zawsze monitoruj `Seconds_Behind_Master` po zwolnieniu blokady.

Interakcja z blokadą metadanych: W MySQL 5.7+ `FTWRL` czeka na zakończenie wszystkich aktywnych transakcji przed uzyskaniem globalnej blokady. Na zajętym serwerze z długo działającymi transakcjami to oczekiwanie może być nieokreślone. Użyj `SHOW PROCESSLIST` do identyfikacji blokujących transakcji przed wykonaniem `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL utrzymuje pamięć podręczną hostów, która rejestruje historię prób połączeń, w tym liczbę nieudanych uwierzytelnień. Gdy host zgromadzi więcej niż `max_connect_errors` kolejnych nieudanych połączeń, MySQL blokuje wszystkie kolejne połączenia z tego hosta do momentu wyczyszczenia wpisu w pamięci podręcznej.

Kiedy używać:

• Gdy legalny host klienta jest zablokowany z powodu przekroczenia `max_connect_errors`
• Po rozwiązaniu problemu sieciowego, który spowodował powtarzające się błędy połączeń TCP
• Po zmianie rekordów DNS wpływających na sposób rozwiązywania nazw hostów klientów przez serwer

Alternatywa w MySQL 8.0: W MySQL 8.0+ możesz również bezpośrednio obciąć tabelę pamięci podręcznej hostów:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Osiąga to ten sam wynik i jest bardziej przejrzyste w zautomatyzowanych skryptach.

Konfiguracja proaktywna: Zamiast reaktywnie polegać na `FLUSH HOSTS`, ustaw `max_connect_errors` na wyższą wartość (np. `10000`) lub ustaw `host_cache_size = 0`, aby całkowicie wyłączyć pamięć podręczną hostów w zaufanych sieciach wewnętrznych.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Resetuje większość zmiennych stanu sesji i globalnych do zera. Obejmuje to liczniki takie jak `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` i setki innych udostępnianych przez `SHOW STATUS` lub `performance_schema`.

Kiedy używać:

• Bezpośrednio przed kontrolowanym testem porównawczym w celu ustalenia czystego punktu odniesienia pomiaru
• Po zmianie konfiguracji (np. dostosowaniu `innodb_buffer_pool_size`) w celu izolacji wpływu na metryki I/O
• Podczas tworzenia skryptów testów regresji wydajności porównujących delty liczników przed/po

Ważne ograniczenie: `FLUSH STATUS` nie resetuje wszystkich liczników. Zmienne takie jak `Uptime`, `Uptime_since_flush_status` i niektóre wewnętrzne metryki InnoDB nie są objęte. W celu kompleksowego monitorowania używaj bezpośrednio tabel `performance_schema`, które oferują szczegółowość na poziomie wątku i zdarzenia, której `FLUSH STATUS` nie może zapewnić.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` zamyka i ponownie otwiera wszystkie pliki dziennika serwera. MySQL 5.7.2+ wprowadził możliwość opróżniania poszczególnych typów dzienników osobno, co jest znacznie lepszym rozwiązaniem w środowisku produkcyjnym.

Kiedy używać:

• Jako część skryptu post-rotate `logrotate` w celu zasygnalizowania MySQL, aby otworzył nowy plik dziennika po rotacji starego
• Aby wymusić nowy plik dziennika binarnego (odpowiednik `FLUSH BINARY LOGS`), co zwiększa numer sekwencji dziennika binarnego
• Przed archiwizacją starych dzienników w celu zapewnienia, że wszystkie oczekujące zapisy są opróżnione na dysk

Szczegóły dotyczące dziennika binarnego: `FLUSH BINARY LOGS` tworzy nowy plik dziennika binarnego i zapisuje `Rotate_event` do starego pliku. Jest to właściwy sposób segmentowania dzienników binarnych do archiwizacji odtwarzania do punktu w czasie (PITR). Bieżący plik dziennika binarnego i pozycję można potwierdzić za pomocą `SHOW MASTER STATUS` (MySQL 5.7) lub `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Przykład integracji z 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;

“`

Ostrzeżenie o wycofaniu: Pamięć podręczna zapytań MySQL została wycofana w MySQL 5.7.20 i całkowicie usunięta w MySQL 8.0. Jeśli używasz MySQL 8.0 lub nowszego, to polecenie nie istnieje.

W środowiskach MySQL 5.6/5.7, gdzie pamięć podręczna zapytań jest nadal aktywna:

• `FLUSH QUERY CACHE` defragmentuje pamięć podręczną zapytań bez usuwania zapisanych w niej wyników
• `RESET QUERY CACHE` całkowicie usuwa wszystkie zapisane wyniki zapytań

Kiedy używać (tylko MySQL 5.6/5.7):

• Po dużej wsadowej modyfikacji danych, która unieważnia znaczną część zapisanych wyników
• Gdy `Qcache_free_blocks` jest wysoki w stosunku do `Qcache_total_blocks`, co wskazuje na fragmentację
• Przed wyłączeniem pamięci podręcznej zapytań (`SET GLOBAL query_cache_size = 0`) w celu czystego zwolnienia pamięci

Nowoczesna alternatywa: W MySQL 8.0+ używaj rozgrzewania puli buforów InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) i `performance_schema` do analizy na poziomie zapytań.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Resetuje liczniki zasobów per-użytkownik śledzone przez wbudowane ograniczanie szybkości MySQL. Te liczniki wymuszają limity zdefiniowane w instrukcjach `CREATE USER` lub `GRANT`:

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

Kiedy używać:

• Gdy użytkownik wyczerpał swój godzinowy limit zapytań i potrzebuje natychmiastowego przywrócenia dostępu przed naturalnym resetem licznika na granicy następnej godziny
• Po zwiększeniu limitów zasobów użytkownika i chęci natychmiastowego wejścia w życie nowych limitów
• Podczas programowania/testowania w celu resetowania limitów między uruchomieniami testów

Uwaga: To polecenie resetuje liczniki dla wszystkich użytkowników jednocześnie. Na poziomie `FLUSH` nie ma szczegółowości per-użytkownik. Jeśli chcesz zresetować liczniki pojedynczego użytkownika, jedyną opcją jest modyfikacja jego konta za pomocą `ALTER USER`, a następnie wydanie `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Wymusza na wszystkich silnikach pamięci masowej opróżnienie oczekujących buforów zapisu do odpowiednich plików dziennika. W przypadku InnoDB oznacza to opróżnienie bufora dziennika ponawiania (`innodb_log_buffer_size`) do plików dziennika ponawiania InnoDB na dysku.

Kiedy używać:

• Przed wykonaniem zimnej kopii zapasowej plików danych InnoDB w celu zapewnienia spójności dziennika ponawiania
• Podczas rozwiązywania problemów z silnikiem pamięci masowej w celu wykluczenia niespójności danych związanych z buforem
• Jako część listy kontrolnej przed konserwacją przed zatrzymaniem usługi MySQL

Kontekst trwałości InnoDB: Ustawienie `innodb_flush_log_at_trx_commit` InnoDB kontroluje, jak agresywnie dziennik ponawiania jest opróżniany przy każdym zatwierdzeniu transakcji. `FLUSH ENGINE LOGS` jest ręcznym nadpisaniem, które wymusza opróżnienie niezależnie od tego ustawienia. Jest to przydatne w scenariuszach, gdzie potrzebny jest gwarantowany punkt kontrolny trwałości bez zatwierdzania transakcji.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Przeładowuje plik klucza szyfrowania DES określony przez opcję uruchamiania serwera `–des-key-file`. Ten plik klucza był używany przez funkcje `DES_ENCRYPT()` i `DES_DECRYPT()`.

Ostrzeżenie o wycofaniu: Funkcje `DES_ENCRYPT()` i `DES_DECRYPT()` zostały wycofane w MySQL 5.7.6 i usunięte w MySQL 8.0. To polecenie jest zatem istotne tylko w starszych instalacjach MySQL 5.6/5.7.

Nowoczesna alternatywa szyfrowania: Używaj natywnego szyfrowania danych w spoczynku MySQL (szyfrowanie przestrzeni tabel InnoDB przez `ALTER TABLE … ENCRYPTION='Y'`) w połączeniu z wtyczkami MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) dla produkcyjnych wymagań szyfrowania.

Tabela porównawcza poleceń FLUSH

Replikacja i FLUSH: co jest replikowane

Nie wszystkie polecenia `FLUSH` są replikowane do serwerów replik. Zrozumienie tej różnicy jest krytyczne w topologiach HA i replikacji:

Domyślnie replikowane:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (zapisywane jako `Rotate_event` w dzienniku binarnym)
• `FLUSH USER_RESOURCES`

Niereplikowane (lokalne dla sesji lub jawnie wykluczone):

• `FLUSH TABLES WITH READ LOCK` — nigdy nie zapisywane do dziennika binarnego
• `FLUSH STATUS` — wpływa tylko na liczniki lokalnego serwera
• `FLUSH HOSTS` — tylko lokalna pamięć podręczna hostów
• `FLUSH ENGINE LOGS` — tylko lokalny stan silnika

Aby zapobiec replikacji konkretnego polecenia `FLUSH` nawet wtedy, gdy normalnie by było replikowane, użyj modyfikatora `LOCAL` lub `NO_WRITE_TO_BINLOG`:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Jest to przydatne podczas niezależnego zarządzania uprawnieniami na replice (np. dodawania użytkowników monitorowania, którzy nie powinni istnieć na serwerze głównym).

Automatyzacja operacji FLUSH za pomocą mysqladmin

Wiele operacji `FLUSH` można uruchomić z powłoki bez otwierania sesji klienta MySQL, co jest przydatne w zadaniach cron i skryptach konserwacyjnych:

“`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

“`

W środowiskach produkcyjnych przechowuj poświadczenia w `~/.my.cnf` z `chmod 600` zamiast przekazywać `-p` interaktywnie lub używaj mechanizmu `–login-path` MySQL z `mysql_config_editor`.

Uwagi dotyczące środowiska hostingowego

Możliwość wykonywania poleceń `FLUSH` zależy w dużej mierze od środowiska hostingowego i poziomu przyznanego dostępu do bazy danych. W planie Hosting VPS zazwyczaj masz pełny dostęp root do instancji MySQL, co oznacza, że możesz wykonywać dowolny wariant `FLUSH`, modyfikować `my.cnf` i zarządzać rotacją dzienników bezpośrednio. Jest to minimalne zalecane środowisko dla wszelkich poważnych prac administracyjnych z bazami danych.

W przypadku Hostingu współdzielonego dostęp do bazy danych jest zazwyczaj ograniczony do użytkownika bez uprawnień bez uprawnienia `RELOAD`, co sprawia, że większość poleceń `FLUSH` jest niedostępna. Jeśli Twoja aplikacja wymaga zarządzania uprawnieniami, kontroli rotacji dzienników lub spójnych migawek kopii zapasowych, środowisko współdzielone będzie twardą przeszkodą.

W przypadku obciążeń baz danych o wysokiej przepustowości — szczególnie tych obejmujących częste operacje `FLUSH ENGINE LOGS` lub duże pule buforów InnoDB — Serwery dedykowane zapewniają przepustowość I/O i przepustowość pamięci potrzebną do tego, aby te operacje były niezakłócające. `FLUSH TABLES WITH READ LOCK` na serwerze z 256 GB danych puli buforów trwa mierzalnie dłużej niż na serwerze z szybką pamięcią masową NVMe i dedykowanymi kanałami I/O.

Jeśli zarządzasz instancją MySQL wraz z panelem sterowania WWW, VPS z cPanel zapewnia zarządzane środowisko, w którym niektóre operacje `FLUSH` (szczególnie rotacja dzienników i przeładowania uprawnień) są obsługiwane automatycznie przez warstwę zarządzania bazami danych panelu sterowania, zmniejszając potrzebę ręcznej interwencji.

W przypadku aplikacji opartych na bazach danych wymagających pełnego ekosystemu panelu sterowania, przejrzenie dostępnych Paneli sterowania VPS pomoże zidentyfikować, który panel najlepiej integruje się z Twoim przepływem pracy administracji MySQL.

Lista kontrolna kluczowych wniosków

Użyj tej macierzy decyzyjnej przed wykonaniem dowolnego polecenia `FLUSH` w środowisku produkcyjnym:

• Przed `FLUSH TABLES WITH READ LOCK`: Potwierdź, że żadne długo działające transakcje nie są aktywne (`SHOW PROCESSLIST`). Sprawdź, czy Twoja baza danych jest wyłącznie InnoDB — jeśli tak, użyj zamiast tego `–single-transaction`.
• Przed `FLUSH PRIVILEGES`: Potwierdź, że używasz surowego DML na tabelach uprawnień. Jeśli użyłeś `GRANT`/`REVOKE`, to polecenie jest zbędne.
• Przed `FLUSH LOGS`: Upewnij się, że Twój skrypt rotacji dzienników już przeniósł/zmienił nazwę starego pliku dziennika przed zasygnalizowaniem MySQL, aby go ponownie otworzył.
• Przed `FLUSH HOSTS`: Najpierw zidentyfikuj główną przyczynę błędów połączeń. Opróżnienie pamięci podręcznej hostów bez naprawienia podstawowego problemu spowoduje ponowne zablokowanie hosta.
• W MySQL 8.0+: Usuń wszelkie wywołania `FLUSH QUERY CACHE` lub `FLUSH DES_KEY_FILE` ze skryptów — te polecenia nie istnieją i spowodują błędy.
• W topologiach replikacji: Używaj `FLUSH LOCAL` lub `FLUSH NO_WRITE_TO_BINLOG`, gdy operacja nie powinna być propagowana do replik.
• Do automatyzacji: Używaj poleceń `mysqladmin flush-*` w skryptach zamiast otwierania pełnych sesji klienta MySQL.
• Audyt uprawnień: Preferuj dynamiczne uprawnienia MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES` itp.) zamiast szerokiego uprawnienia `RELOAD` dla kont monitorowania i kopii zapasowych.

Często zadawane pytania

Czy FLUSH PRIVILEGES musi być uruchamiany po każdej instrukcji GRANT lub REVOKE?

Nie. `GRANT`, `REVOKE`, `CREATE USER` i `DROP USER` automatycznie przeładowują tabele uprawnień w pamięci. `FLUSH PRIVILEGES` jest konieczny tylko po bezpośrednich modyfikacjach DML tabel systemowych `mysql` (np. `UPDATE mysql.user SET …`).

Czy FLUSH TABLES WITH READ LOCK może spowodować przestój aplikacji?

Tak. Uzyskuje globalną blokadę zapisu, która blokuje wszystkie operacje `INSERT`, `UPDATE`, `DELETE` i DDL we wszystkich bazach danych na serwerze. W zajętym systemie OLTP nawet kilka sekund `FTWRL` może wyczerpać pule połączeń i spowodować kaskadowe błędy aplikacji. W przypadku baz danych wyłącznie InnoDB używaj `mysqldump –single-transaction`, aby całkowicie tego uniknąć.

Czy FLUSH STATUS jest tym samym co restart serwera MySQL dla celów testów porównawczych?

Nie. `FLUSH STATUS` resetuje większość liczników stanu, ale nie czyści puli buforów InnoDB, nie resetuje stanów połączeń ani nie wpływa na skumulowane statystyki `performance_schema`. W celu prawdziwie czystego testu porównawczego dokładniejszy jest restart serwera połączony z czyszczeniem puli buforów, choć niepraktyczny w środowisku produkcyjnym.

Dlaczego FLUSH HOSTS nie istnieje jako samodzielne polecenie w niektórych dokumentacjach MySQL 8.0?

`FLUSH HOSTS` nadal działa w MySQL 8.0, ale preferowaną metodą jest `TRUNCATE TABLE performance_schema.host_cache`, która jest bardziej przejrzysta i może być wykonana bez uprawnienia `RELOAD`, jeśli użytkownik ma `DELETE` na `performance_schema`. Obie osiągają ten sam wynik.

Co się dzieje, gdy FLUSH ENGINE LOGS jest wykonywany podczas szczytowego obciążenia zapisu w InnoDB?

Wymusza synchroniczne opróżnienie bufora dziennika InnoDB na dysk, co może spowodować krótki przestój zapisu, jeśli pliki dziennika ponawiania znajdują się na wolnej pamięci masowej. Na serwerach z pamięcią masową NVMe wpływ jest zazwyczaj poniżej milisekundy. Na dyskach obrotowych lub mocno obciążonej pamięci masowej SAN może powodować zauważalne skoki opóźnień. Planuj tę operację w oknach niskiego ruchu, gdy to możliwe.