問題：
磁盤 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 的技術內容，你們還有什麼想知道的嗎？趕緊留言告訴小編吧！
閱讀更多 愛可生 的文章
