問題：

磁碟 IO 報警，說 IO 飽和了。那麼 MySQL 讀寫哪個檔案慢了？binlog？redo log？還是哪張表？

構造環境：

根據先前的 實驗 02，構造環境，模仿 binlog 的磁碟 IO 慢。

實驗：

想觀察 IO 相關的行為，需啟用 performance_schema 的 instrument（生產者）和 consumer（消費者）。

將 performance_schema 的配置重置為預設配置，IO 相關的 instrument（生產者）在預設配置裡開啟。

啟用 waits 相關的 consumer（消費者）

將已記錄的效能資料清零

向 MySQL 施加壓力

在另一個 session 中，觀察最近的 IO 行為。

可以看到 binlog 的刷盤 IO 明顯比其他操作慢，符合我們構造的實驗場景。這樣我們就快速定位了哪個檔案的 IO 變慢了。

有了執行緒號，我們還可以定位其對應的操作：

結論：

我們通過 sys.x$latest_file_io，找到最近的 IO 操作的記錄，進行了排序。

需注意：

1. 這裡不用 sys.latest_file_io 的原因是無法對操作延遲進行排序。

小知識：

以 sys 中, 以 x$ 開頭的檢視，是原始資料。

不以 x$ 開頭的檢視，是給人類看的檢視（比如時間顯示會帶單位，顯示成 123 ns）。

2. sys.x$latest_file_io 檢視涉及到兩張表：performance_schema

.events_waits_history_long和performance_schema.threads如果某個執行緒退出，就不會出現在 sys.x$latest_file_io 檢視。所以 sys.x$latest_file_io 不是”最近的 IO 操作記錄”，而是”當前活躍執行緒的最近的 IO 操作記錄”。

原文