問題：

磁盤 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 操作記錄"。

---

關于 MySQL 的技術內容，你們還有什么想知道的嗎？趕緊留言告訴小編吧！

總結

以上是生活随笔為你收集整理的mysql 视图慢_第03问：磁盘 IO 报警，MySQL 读写哪个文件慢了？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。