MySQL 5.7 Performance Schema 官方手冊深度導讀：架構、配置、監控與診斷實戰

Performance Schema 核心定位

MySQL 服務層運行時的底層效能監控框架。不同於 INFORMATION_SCHEMA 關注元數據，PS 專注效能數據：等待事件、階段、語句、事務、鎖、內存、復制等微觀指標。資料儲於 performance_schema 資料庫 (Memory 引擎，非持久化)，支援動態配置、SQL 查詢分析。

快速啟用與驗證

-- my.cnf 永久啟用
[mysqld]
performance_schema = ON

-- 運行時檢查
SHOW VARIABLES LIKE 'performance_schema'; -- ON 表示啟用成功

-- 檢查引擎支援
SHOW ENGINES; -- PERFORMANCE_SCHEMA 行 Support = YES

核心對象模型：生產者-消費者

• Instruments (生產者/記錄點)： 埋點在原始碼，命名如 wait/io/file/innodb/innodb_data_file。setup_instruments 控制啟用/計時。
• Consumers (消費者/目標表)： 決定事件流向哪張表 (current/history/summary)。setup_consumers 控制啟用。
• Pre-filtering (預過濾)： 修改 setup 表，全局生效，降低開銷。
• Post-filtering (事後過濾)： 查詢 PS 表時加 WHERE 條件。

關鍵配置表 (Setup Tables)

消費者層級依賴關係 (自上而下)

1. global_instrumentation (總開關) →
2. thread_instrumentation (線程級) →
3. events_xxx_current (當前事件) →
4. events_xxx_history / events_xxx_history_long (歷史)

上層關閉，下層不再被檢查/生成事件。

核心監控表分類

1. 實例表 (Object Instances) - 靜態快照

• file_instances：開啟的檔案 IO 對象。
• mutex_instances / rwlock_instances / cond_instances：同步原語實例 (含持有者線程 ID)。
• socket_instances：實時連線快照 (IP、Port、State=ACTIVE/IDLE)。

2. 事件等待表 (Wait Events) - 微觀延遲分析

• events_waits_current：每線程當前正在等待什麼 (鎖、IO、網路)。
• events_waits_history：每線程最近 N 次等待 (預設 10)。
• events_waits_history_long：全局最近 N 次等待 (預設 10000)。

分子事件特性： 表 IO 等待 (wait/io/table/sql/handler) 會嵌套檔案 IO 等待，current 表中會同時出現兩行 (外層 TABLE IO、內層 FILE IO)。

3. 階段/語句/事務事件表 - 宏觀 SQL 分析

• Stage (階段)： stage/sql/Sorting result, stage/sql/Copying to tmp table 等。5.7.5+ 提供 WORK_COMPLETED/WORK_ESTIMATED 進度百分比。
• Statement (語句)： 含 DIGEST_TEXT (標準化 SQL) 與 DIGEST (MD5)。支援 events_statements_summary_by_digest 發現高頻/慢查詢模式。
• Transaction (事務)： 記錄隔離級別、存取模式、隱式/顯式提交。嵌套關係：Transaction → Statement → Stage → Wait。

4. 統計摘要表 (Summary Tables) - 聚合視角

• 按事件名全局彙總：events_waits_summary_global_by_event_name (排序 COUNT_STAR 或 SUM_TIMER_WAIT 找熱點)。
• 按線程/帳號/主機/用戶彙總：events_xxx_summary_by_thread_by_event_name 等。
• 檔案 IO、表 IO/鎖、Socket、內存、狀態變數等多維度摘要。

Statement Digests：SQL 指紋識別

• 標準化：字面值替換為 ?，移除註釋、調整空格。SELECT * FROM t WHERE id=1 → SELECT * FROM t WHERE id = ?。
• DIGEST_TEXT (標準化文本) + DIGEST (MD5 Hash)。
• performance_schema_max_digest_length (預設 1024B) 控制標準化長度。
• events_statements_summary_by_digest 表提供：執行次數、總延遲、平均延遲、掃描行數、臨時表/磁盤表創建次數等關鍵指標。

實戰診斷工作流

1. 重現問題負載。
2. 全開 Instruments/Consumers (UPDATE setup_instruments SET ENABLED=YES, TIMED=YES; UPDATE setup_consumers SET ENABLED=YES;)。
3. 查詢 events_waits_summary_global_by_event_name 找 SUM_TIMER_WAIT 最高的等待類型 (如 wait/synch/mutex/... 鎖熱點)。
4. 針對性關閉無關 Instruments (如不關心 File IO 關閉 wait/io/file/%) 降低干擾。
5. 鎖定問題線程：SELECT * FROM events_waits_current WHERE THREAD_ID = ? 看等待什麼鎖 (OBJECT_INSTANCE_BEGIN)。
6. 反查持有者：SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = ? 獲取 LOCKED_BY_THREAD_ID。
7. 檢視持有者在幹嘛：SELECT * FROM events_waits_current WHERE THREAD_ID = holder_id。
8. 根據根因調優：參數、索引、SQL 改寫、架構調整。
9. 驗證效果，迭代優化。

遷移指南：從 INFORMATION_SCHEMA 到 PS

MySQL 5.7.6+ 將系統/狀態變數表遷移至 PS：

• performance_schema.global_variables / session_variables / variables_by_thread
• performance_schema.global_status / session_status / status_by_thread/account/host/user

show_compatibility_56=ON 兼容模式下 SHOW VARIABLES/STATUS 仍查 INFORMATION_SCHEMA 並警告；關閉後直接查 PS 表並要求 SELECT 權限。未來版本將移除 INFORMATION_SCHEMA 相關表與兼容參數。

內存分配模型演進 (5.7.6+)

• 5.7.6 前： 啟動時一次性分配所有配置大小的內存，靜態固定。
• 5.7.6+： 自動擴容。參數設為 -1 (預設) 表示自動：啟動不分配，按需增長，無上限 (受限於系統記憶體)。設為 0 禁用該類收集。設為 N>0 固定上限，超限丟棄事件並增加 _lost 狀態計數。
• 監控內存佔用：SELECT * FROM memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%';