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

版本 9.0

8.4 目前
8.0
5.7

8.0 日文

MySQL 9.0 參考手冊 / ... / 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.9 節，「預存程式的限制」。

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

注意

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

FLUSH 陳述式會導致隱含的 commit。請參閱第 15.3.3 節，「導致隱含 Commit 的陳述式」。

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

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

RESET 陳述式類似於 FLUSH。請參閱第 15.7.8.6 節，「RESET 陳述式」，以取得有關將 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 則有不同的適用方式，它會將表格內容刷新到磁碟，但保持它們開啟。只要其他活動沒有修改表格，這仍然允許在表格開啟時複製表格檔案。

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 變體可讓表格在單一操作中被刷新和鎖定。它為 FLUSH TABLES 在有作用中的 LOCK TABLES ... READ 時不允許使用的限制提供了一個解決方法。
此操作不會執行隱式的 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 表格。
FLUSH TABLES ...FOR EXPORT 支援分割的 InnoDB 表格。
當收到 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
```

上一個首頁上一層下一個