MySQL :: MySQL 8.4 參考手冊 :: 15.7.8.3 FLUSH 陳述式

版本 8.4

8.0 日文

MySQL 8.4 參考手冊 / ... / FLUSH 陳述式

15.7.8.3 FLUSH 陳述式

FLUSH [NO_WRITE_TO_BINLOG | LOCAL] {
    flush_option [, flush_option] ...
  | tables_option
}

flush_option: {
    BINARY LOGS
  | ENGINE LOGS
  | ERROR LOGS
  | GENERAL LOGS
  | LOGS
  | PRIVILEGES
  | OPTIMIZER_COSTS
  | RELAY LOGS [FOR CHANNEL channel]
  | SLOW LOGS
  | STATUS
  | USER_RESOURCES
}

tables_option: {
    table_synonym
  | table_synonym tbl_name [, tbl_name] ...
  | table_synonym WITH READ LOCK
  | table_synonym tbl_name [, tbl_name] ... WITH READ LOCK
  | table_synonym tbl_name [, tbl_name] ... FOR EXPORT
}

table_synonym: {
    TABLE
  | TABLES
}

FLUSH 陳述式有數種變體形式，可以清除或重新載入各種內部快取、刷新表格或取得鎖定。每個 FLUSH 操作都需要其描述中指示的權限。

注意

無法在預存函式或觸發器中發出 FLUSH 陳述式。但是，您可以在預存程序中使用 FLUSH，只要這些程序不是從預存函式或觸發器呼叫即可。請參閱第 27.8 節「預存程式的限制」。

預設情況下，伺服器會將 FLUSH 陳述式寫入二進位日誌，以便複製到複本。若要抑制記錄，請指定選用的 NO_WRITE_TO_BINLOG 關鍵字或其別名 LOCAL。

注意

FLUSH LOGS、FLUSH BINARY LOGS、FLUSH TABLES WITH READ LOCK（帶或不帶表格清單）以及 FLUSH TABLES tbl_name ... FOR EXPORT 在任何情況下都不會寫入二進制日誌，因為如果複製到副本，它們會導致問題。

FLUSH 陳述式會導致隱式提交。請參閱第 15.3.3 節，「導致隱式提交的陳述式」。

mysqladmin 公用程式使用諸如 flush-logs、flush-privileges、flush-status 和 flush-tables 等指令，提供對某些 flush 操作的命令列介面。請參閱第 6.5.2 節，「mysqladmin — MySQL 伺服器管理程式」。

向伺服器發送 SIGHUP 或 SIGUSR1 信號會導致發生數個 flush 操作，這些操作與 FLUSH 陳述式的各種形式類似。信號可以由 root 系統帳戶或擁有伺服器處理程序的系統帳戶發送。這使得可以執行 flush 操作，而無需連線到伺服器，這需要具有足夠操作權限的 MySQL 帳戶。請參閱第 6.10 節，「MySQL 中的 Unix 信號處理」。

RESET 陳述式類似於 FLUSH。如需關於搭配複製使用 RESET 的資訊，請參閱第 15.7.8.6 節，「RESET 陳述式」。

以下清單描述允許的 FLUSH 陳述式 flush_option 值。如需允許的 tables_option 值的說明，請參閱「FLUSH TABLES 語法」。

FLUSH BINARY LOGS
關閉並重新開啟伺服器正在寫入的任何二進制日誌檔案。如果已啟用二進制記錄，則二進制日誌檔案的序號會相較於上一個檔案遞增一。
此操作需要 RELOAD 權限。
FLUSH ENGINE LOGS
關閉並重新開啟已安裝儲存引擎的任何可刷新日誌。這會導致 InnoDB 將其日誌刷新到磁碟。
此操作需要 RELOAD 權限。
FLUSH ERROR LOGS
關閉並重新開啟伺服器正在寫入的任何錯誤日誌檔案。
此操作需要 RELOAD 權限。
FLUSH GENERAL LOGS
關閉並重新開啟伺服器正在寫入的任何一般查詢日誌檔案。
此操作需要 RELOAD 權限。
此操作對用於一般查詢日誌的表格沒有影響（請參閱第 7.4.1 節，「選取一般查詢日誌和慢速查詢日誌輸出目的地」）。
FLUSH LOGS
關閉並重新開啟伺服器正在寫入的任何日誌檔案。
此操作需要 RELOAD 權限。
此操作的效果等同於這些操作的組合效果
```
FLUSH BINARY LOGS
FLUSH ENGINE LOGS
FLUSH ERROR LOGS
FLUSH GENERAL LOGS
FLUSH RELAY LOGS
FLUSH SLOW LOGS
```
FLUSH OPTIMIZER_COSTS
重新讀取成本模型表，以便最佳化工具開始使用其中儲存的目前成本估計。
此操作需要 FLUSH_OPTIMIZER_COSTS 或 RELOAD 權限。
伺服器會針對任何無法辨識的成本模型表項目，將警告寫入錯誤日誌。如需這些表格的相關資訊，請參閱第 10.9.5 節，「最佳化工具成本模型」。此操作只會影響在刷新之後開始的階段作業。現有的階段作業會繼續使用在其開始時有效的成本估計。
FLUSH PRIVILEGES
從 mysql 系統綱要中的授權表格重新讀取授權。作為此操作的一部分，伺服器會讀取包含動態權限指派的 global_grants 表格，並註冊在那裡找到的任何未註冊權限。
只有在您直接對授權表格進行此類變更時，重新載入授權表格才能啟用對 MySQL 權限和使用者的更新；對於諸如 GRANT 或 REVOKE 等立即生效的帳戶管理陳述式，則不需要重新載入。如需更多資訊，請參閱第 8.2.13 節，「權限變更何時生效」。
此操作需要 RELOAD 或 FLUSH_PRIVILEGES 權限。
如果在伺服器啟動時指定 --skip-grant-tables 選項以停用 MySQL 權限系統，則 FLUSH PRIVILEGES 提供在執行階段啟用權限系統的方法。
重設失敗的登入追蹤（或在伺服器以 --skip-grant-tables 啟動時啟用它）並解鎖任何暫時鎖定的帳戶。請參閱第 8.2.15 節，「密碼管理」。
釋放伺服器由於 GRANT、CREATE USER、CREATE SERVER 和 INSTALL PLUGIN 陳述式而快取的記憶體。此記憶體不會由對應的 REVOKE、DROP USER、DROP SERVER 和 UNINSTALL PLUGIN 陳述式釋放，因此，對於執行許多導致快取之陳述式的伺服器，快取記憶體的使用量會增加，除非使用 FLUSH PRIVILEGES 釋放它。
清除 caching_sha2_password 驗證外掛程式使用的記憶體內快取。請參閱SHA-2 可插入式驗證的快取操作。
FLUSH RELAY LOGS [FOR CHANNEL channel]
關閉並重新開啟伺服器正在寫入的任何中繼日誌檔案。如果已啟用中繼記錄，則中繼日誌檔案的序號會相較於上一個檔案遞增一。
此操作需要 RELOAD 權限。
FOR CHANNEL channel 子句可讓您指定操作套用到的複製通道。執行 FLUSH RELAY LOGS FOR CHANNEL channel 以刷新特定複製通道的中繼日誌。如果未指定通道且不存在額外的複製通道，則操作會套用到預設通道。如果未指定通道且存在多個複製通道，則操作會套用到所有複製通道。如需更多資訊，請參閱第 19.2.2 節，「複製通道」。
FLUSH SLOW LOGS
關閉並重新開啟伺服器正在寫入的任何慢速查詢日誌檔案。
此操作需要 RELOAD 權限。
此操作對用於慢速查詢日誌的表格沒有影響（請參閱第 7.4.1 節，「選取一般查詢日誌和慢速查詢日誌輸出目的地」）。
FLUSH STATUS
刷新狀態指示器。
此操作會將目前執行緒的階段作業狀態變數值新增至全域值，並將階段作業值重設為零。某些全域變數也可能會重設為零。它也會將金鑰快取（預設和命名）的計數器重設為零，並將 Max_used_connections 設定為目前的開啟連線數。在偵錯查詢時，此資訊可能很有用。請參閱第 1.6 節，「如何回報錯誤或問題」。
FLUSH STATUS 不受 read_only 或 super_read_only 的影響，而且永遠會寫入二進制日誌。
此操作需要 FLUSH_STATUS 或 RELOAD 權限。
FLUSH USER_RESOURCES
將所有每小時使用者資源指示器重設為零。
此操作需要 FLUSH_USER_RESOURCES 或 RELOAD 權限。
重設資源指示器可讓已達到其每小時連線、查詢或更新限制的用戶端立即恢復活動。FLUSH USER_RESOURCES 不適用於由 max_user_connections 系統變數控制的最大同步連線數限制。請參閱第 8.2.21 節，「設定帳戶資源限制」。

FLUSH TABLES 語法

FLUSH TABLES 會刷新表格，並根據所使用的變體取得鎖定。在 FLUSH 陳述式中使用的任何 TABLES 變體都必須是使用的唯一選項。FLUSH TABLE 是 FLUSH TABLES 的同義字。

注意

此處表示透過關閉表格來刷新表格的說明，對於 InnoDB 適用方式不同，InnoDB 會將表格內容刷新到磁碟，但讓它們保持開啟狀態。這仍然允許在表格開啟時複製表格檔案，只要其他活動沒有修改它們即可。

FLUSH TABLES
關閉所有開啟的表格、強制關閉所有使用中的表格，並刷新準備好的陳述式快取。
此操作需要 FLUSH_TABLES 或 RELOAD 權限。
關於預處理語句快取的資訊，請參閱第 10.10.3 節，「預處理語句和儲存程序的快取」。
當存在活動的LOCK TABLES ... READ時，不允許使用FLUSH TABLES。要刷新和鎖定資料表，請改用FLUSH TABLES tbl_name ... WITH READ LOCK。
FLUSH TABLES tbl_name [, tbl_name] ...
使用一個或多個逗號分隔的資料表名稱清單，此操作類似於沒有名稱的FLUSH TABLES，只是伺服器僅刷新指定的資料表。如果指定的資料表不存在，則不會發生錯誤。
此操作需要 FLUSH_TABLES 或 RELOAD 權限。
FLUSH TABLES WITH READ LOCK
關閉所有開啟的資料表，並以全域讀取鎖鎖定所有資料庫的所有資料表。
此操作需要 FLUSH_TABLES 或 RELOAD 權限。
如果您有像 Veritas 或 ZFS 這樣的檔案系統，可以進行時間快照，此操作是一種非常方便的備份方式。使用UNLOCK TABLES來釋放鎖定。
FLUSH TABLES WITH READ LOCK取得全域讀取鎖，而不是資料表鎖，因此它不受LOCK TABLES和UNLOCK TABLES在資料表鎖定和隱含提交方面的相同行為約束。
- 只有在目前有任何資料表被LOCK TABLES鎖定時，UNLOCK TABLES才會隱含地提交任何活動的事務。對於FLUSH TABLES WITH READ LOCK之後的UNLOCK TABLES，不會發生提交，因為後者語句不會取得資料表鎖。
- 開始事務會導致使用LOCK TABLES取得的資料表鎖被釋放，就像您已執行UNLOCK TABLES一樣。開始事務不會釋放使用FLUSH TABLES WITH READ LOCK取得的全域讀取鎖。
FLUSH TABLES WITH READ LOCK不會阻止伺服器將資料列插入日誌資料表（請參閱第 7.4.1 節，「選擇一般查詢日誌和慢速查詢日誌輸出目的地」）。
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK
刷新並取得指定資料表的讀取鎖。
此操作需要FLUSH_TABLES或RELOAD權限。因為它會取得資料表鎖定，因此也需要每個資料表的LOCK TABLES權限。
該操作首先會取得資料表的獨佔中繼資料鎖定，因此它會等待具有開啟這些資料表的交易完成。然後，該操作會將資料表從資料表快取中刷新，重新開啟資料表，取得資料表鎖定（例如LOCK TABLES ... READ），並將中繼資料鎖從獨佔降級為共用。在操作取得鎖定並降級中繼資料鎖定後，其他會話可以讀取但不能修改資料表。
此操作僅適用於現有的基本（非TEMPORARY）資料表。如果名稱參照基本資料表，則使用該資料表。如果它參照TEMPORARY資料表，則會被忽略。如果名稱適用於檢視表，則會發生ER_WRONG_OBJECT錯誤。否則，會發生ER_NO_SUCH_TABLE錯誤。
使用UNLOCK TABLES來釋放鎖定，LOCK TABLES來釋放鎖定並取得其他鎖定，或START TRANSACTION來釋放鎖定並開始新的交易。
此FLUSH TABLES變體允許在單一操作中刷新和鎖定資料表。它為限制提供了一個解決方法，即當存在活動的LOCK TABLES ... READ時，不允許使用FLUSH TABLES。
此操作不會執行隱含的UNLOCK TABLES，因此，如果在存在任何活動的LOCK TABLES時執行此操作，或在未先釋放已取得的鎖定的情況下第二次使用它，則會產生錯誤。
如果刷新後的資料表是使用HANDLER開啟的，則處理常式會被隱含地刷新並失去其位置。
FLUSH TABLES tbl_name [, tbl_name] ... FOR EXPORT
此FLUSH TABLES變體適用於InnoDB資料表。它確保對指定資料表的變更已刷新到磁碟，以便可以在伺服器執行時建立二進位資料表副本。
此操作需要FLUSH_TABLES或RELOAD權限。因為它會在準備匯出時取得資料表鎖定，因此它也需要每個資料表的LOCK TABLES和SELECT權限。
操作方式如下
1. 它會取得指定資料表的共用中繼資料鎖定。只要其他會話有修改過這些資料表或持有它們的資料表鎖定的活動交易，該操作就會被封鎖。取得鎖定後，該操作會封鎖嘗試更新資料表的交易，同時允許繼續執行唯讀操作。
2. 它會檢查資料表的所有儲存引擎是否支援FOR EXPORT。如果有任何一個不支援，則會發生ER_ILLEGAL_HA錯誤，且操作失敗。
3. 該操作會通知每個資料表的儲存引擎，使資料表準備好進行匯出。儲存引擎必須確保將任何待處理的變更寫入磁碟。
4. 該操作會將會話置於鎖定資料表模式，以便在FOR EXPORT操作完成時，不會釋放先前取得的中繼資料鎖定。
此操作僅適用於現有的基本（非TEMPORARY）資料表。如果名稱參照基本資料表，則使用該資料表。如果它參照TEMPORARY資料表，則會被忽略。如果名稱適用於檢視表，則會發生ER_WRONG_OBJECT錯誤。否則，會發生ER_NO_SUCH_TABLE錯誤。
InnoDB 支援具有自己的.ibd 檔案的資料表（也就是說，使用啟用innodb_file_per_table設定建立的資料表）的 FOR EXPORT。InnoDB 在收到 FOR EXPORT 操作通知時，會確保將任何變更刷新到磁碟。這允許在 FOR EXPORT 操作生效時建立資料表內容的二進位副本，因為 .ibd 檔案是交易一致的，並且可以在伺服器執行時複製。 FOR EXPORT 不適用於 InnoDB 系統資料表空間檔案，也不適用於具有 FULLTEXT 索引的 InnoDB 資料表。
分割區的 InnoDB 資料表支援FLUSH TABLES ...FOR EXPORT。
當收到 FOR EXPORT 通知時，InnoDB 會將通常儲存在記憶體中或資料表空間檔案之外的單獨磁碟緩衝區中的某些資料寫入磁碟。對於每個資料表，InnoDB 還會在與資料表相同的資料庫目錄中產生一個名為 table_name.cfg 的檔案。 .cfg 檔案包含稍後將資料表空間檔案重新匯入相同或不同伺服器所需的中繼資料。
當 FOR EXPORT 操作完成時，InnoDB 會將所有髒頁刷新到資料表資料檔案中。任何變更緩衝區的條目都會在刷新之前合併。此時，資料表會被鎖定且處於靜止狀態：這些資料表在磁碟上處於交易一致的狀態，您可以複製 .ibd 表空間檔案以及相應的 .cfg 檔案，以取得這些資料表的一致快照。
關於如何將複製的資料表資料重新匯入 MySQL 實例的程序，請參閱第 17.6.1.3 節，「匯入 InnoDB 資料表」。
在您完成資料表操作後，請使用 UNLOCK TABLES 來釋放鎖定，使用 LOCK TABLES 來釋放鎖定並取得其他鎖定，或使用 START TRANSACTION 來釋放鎖定並開始新的交易。
當任何這些陳述式在會話中生效時，嘗試使用 FLUSH TABLES ... FOR EXPORT 將會產生錯誤。
```
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
LOCK TABLES ... READ
LOCK TABLES ... WRITE
```
當 FLUSH TABLES ... FOR EXPORT 在會話中生效時，嘗試使用任何這些陳述式將會產生錯誤。
```
FLUSH TABLES WITH READ LOCK
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
```