在 MySQL 5.7 及以上版本中，performance_schema（簡稱 P_S） 是官方推薦的、用于替代 SHOW PROFILES 的低開銷性能監(jiān)控機(jī)制。

它默認(rèn)開啟（無需手動啟用），通過一系列系統(tǒng)表實時收集 SQL 執(zhí)行、鎖等待、I/O、內(nèi)存等詳細(xì)性能數(shù)據(jù)。

一、performance_schema是什么

performance_schema 是一個「數(shù)據(jù)庫」（Database / Schema）

在 MySQL 中，performance_schema 是 內(nèi)置的系統(tǒng)數(shù)據(jù)庫之一，和以下這些是同一類：

• mysql：存儲用戶、權(quán)限等元數(shù)據(jù)
• information_schema：提供元數(shù)據(jù)視圖（如表結(jié)構(gòu)、列信息）
• sys：基于 performance_schema 的簡化視圖（MySQL 5.7+）
• performance_schema：提供底層性能監(jiān)控數(shù)據(jù)

你可以用以下命令驗證：

輸出

編輯
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |  ← 看！它是一個數(shù)據(jù)庫！
| sys                |
| your_app_db        |
+--------------------+

它里面有很多「表」，但這些表是「內(nèi)存中的虛擬表」

進(jìn)入 performance_schema 數(shù)據(jù)庫后，你可以看到很多表：

USE performance_schema;
SHOW TABLES;

你會看到上百張表，例如：

• events_statements_current
• events_statements_history
• events_statements_summary_by_digest
• events_waits_history
• file_summary_by_instance
• ...

?? 注意：這些表 不是磁盤上的真實文件，而是 MySQL 內(nèi)存中動態(tài)生成的“視圖”或“接口”，用于暴露內(nèi)部性能數(shù)據(jù)。

• 它們 沒有 .frm 或 .ibd 文件
• 你不能 INSERT、UPDATE、DELETE（只讀）
• 查詢它們時，MySQL 會實時從內(nèi)存結(jié)構(gòu)中收集數(shù)據(jù)返回

所以，performance_schema 是一個特殊的只讀系統(tǒng)數(shù)據(jù)庫，它的“表”其實是性能監(jiān)控的 API 接口。

二、高效性能分析

下面以 “監(jiān)控最近執(zhí)行的慢查詢及其耗時” 為例，手把手教你如何使用 performance_schema 進(jìn)行高效性能分析。

第一步：確認(rèn)performance_schema已啟用

SHOW VARIABLES LIKE 'performance_schema';

• 如果返回 ON → 正?？捎茫∕ySQL 5.7+ 默認(rèn)開啟）
• 如果是 OFF → 需在 my.cnf 中添加 performance_schema=ON 并重啟 MySQL

第二步：查看最近執(zhí)行的 SQL 語句（類似SHOW PROFILES）

關(guān)鍵表：events_statements_history

它記錄了每個連接最近執(zhí)行的若干條 SQL（數(shù)量由 performance_schema_events_statements_history_size 控制，默認(rèn) 10 條/連接）。

查看所有最近執(zhí)行的語句（含耗時）：

SELECT 
  THREAD_ID,
  EVENT_ID,
  SQL_TEXT,
  TIMER_WAIT / 1000000000000 AS exec_time_sec  -- 轉(zhuǎn)換為秒
FROM performance_schema.events_statements_history
WHERE SQL_TEXT IS NOT NULL
ORDER BY EVENT_ID DESC
LIMIT 10;

輸出示例：

THREAD_ID | EVENT_ID | SQL_TEXT                     | exec_time_sec
45        | 12345    | SELECT * FROM users WHERE id=1 | 0.0023

TIMER_WAIT 單位是皮秒（picoseconds），除以 10^12 得到秒。

第三步：查看某條 SQL 的詳細(xì)階段耗時（類似SHOW PROFILE）

關(guān)鍵表：events_stages_history

記錄每條 SQL 在各個執(zhí)行階段（如解析、優(yōu)化、執(zhí)行、發(fā)送結(jié)果等）的耗時。

步驟：

1. 先從 events_statements_history 中找到目標(biāo) EVENT_ID
2. 用該 EVENT_ID 查詢對應(yīng)的階段信息：

-- 假設(shè)上一步查到 EVENT_ID = 12345
SELECT 
  EVENT_NAME AS stage,
  TIMER_WAIT / 1000000000000 AS duration_sec
FROM performance_schema.events_stages_history
WHERE NESTING_EVENT_ID = 12345
ORDER BY TIMER_START;

輸出示例：

stage                              | duration_sec
stage/sql/Opening tables           | 0.0001
stage/sql/System lock              | 0.00002
stage/sql/optimizing               | 0.0003
stage/sql/executing                | 0.0015

這就相當(dāng)于 SHOW PROFILE FOR QUERY ... 的效果，但更結(jié)構(gòu)化！

第四步：監(jiān)控“慢查詢”（自動捕獲耗時長的 SQL）

方法：使用events_statements_summary_by_digest

這個表會自動聚合相同模式的 SQL（如 SELECT * FROM t WHERE id=?），并統(tǒng)計平均耗時、最大耗時、執(zhí)行次數(shù)等。

SELECT 
  DIGEST_TEXT AS normalized_sql,     -- 參數(shù)化后的SQL模板
  COUNT_STAR AS exec_count,
  AVG_TIMER_WAIT / 1000000000000 AS avg_time_sec,
  MAX_TIMER_WAIT / 1000000000000 AS max_time_sec,
  SUM_ROWS_EXAMINED / COUNT_STAR AS avg_rows_examined
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST_TEXT IS NOT NULL
ORDER BY avg_time_sec DESC
LIMIT 10;

這是 最實用的性能分析入口！可以快速發(fā)現(xiàn)：

• 哪些 SQL 平均耗時最長？
• 哪些 SQL 掃描行數(shù)最多？
• 哪些 SQL 執(zhí)行頻率最高？

第五步：實時監(jiān)控當(dāng)前正在執(zhí)行的 SQL

使用events_statements_current

SELECT 
  PROCESSLIST_ID AS conn_id,
  SQL_TEXT,
  TIMER_WAIT / 1000000000000 AS running_time_sec
FROM performance_schema.events_statements_current
WHERE SQL_TEXT IS NOT NULL;

結(jié)合 SHOW PROCESSLIST，可定位卡住的查詢。

三、實用技巧 & 注意事項

1. 清空歷史統(tǒng)計（重置計數(shù)器）

TRUNCATE TABLE performance_schema.events_statements_summary_by_digest;

2. 開啟更多監(jiān)控項（默認(rèn)已開啟大部分）

檢查是否啟用 statement 監(jiān)控：

SELECT * FROM performance_schema.setup_consumers 
WHERE NAME LIKE '%statement%';
-- 確保 events_statements_current/history/summary 都是 ENABLED

3. 性能開銷極低

• performance_schema 使用環(huán)形緩沖區(qū)內(nèi)存，不寫磁盤
• 開銷通常 < 5%，遠(yuǎn)低于 profiling=ON

4. 與慢查詢?nèi)罩净パa(bǔ)

• slow_query_log：記錄超過閾值的 SQL（適合長期歸檔）
• performance_schema：實時分析所有 SQL（適合開發(fā)調(diào)試）

四、總結(jié)：如何替代SHOW PROFILES

五、推薦日常使用命令

-- 1. 查看最近10條SQL及耗時
SELECT 
    SQL_TEXT, TIMER_WAIT/1e12 AS sec 
FROM 
    performance_schema.events_statements_history 
ORDER BY 
    EVENT_ID 
DESC LIMIT 10;

-- 2. 查找最慢的SQL模板
SELECT 
    DIGEST_TEXT, AVG_TIMER_WAIT/1e12 AS avg_sec 
FROM 
    performance_schema.events_statements_summary_by_digest 
ORDER BY 
    avg_sec 
DESC LIMIT 5;

通過 performance_schema，你不僅能獲得比 SHOW PROFILES 更豐富的信息，還能實現(xiàn)自動化監(jiān)控、告警和根因分析，是現(xiàn)代 MySQL 性能調(diào)優(yōu)的必備技能。

到此這篇關(guān)于mysql使用 performance_schema 進(jìn)行性能監(jiān)控的文章就介紹到這了,更多相關(guān)mysql使用performance_schema進(jìn)行性能監(jiān)控內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論