SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- 記錄超過1秒的查詢
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

• ?使用工具分析日志?：
  • ?**pt-query-digest（Percona Toolkit）?**?：

pt-query-digest /var/log/mysql/slow.log --limit 10  -- 輸出消耗最高的前10個(gè)查詢

• ?輸出結(jié)果關(guān)注點(diǎn)?：
  • Table：被頻繁操作的表名。
  • Rows_examined：掃描行數(shù)過大（如百萬級）的表。
  • Query_time：單次執(zhí)行耗時(shí)長的 SQL。

?方法 3：通過 Performance Schema 定位表級操作?

-- 查看消耗 CPU 最高的 SQL 及其操作的表
SELECT 
  DIGEST_TEXT AS query,
  SCHEMA_NAME AS db,
  COUNT_STAR AS exec_count,
  SUM_TIMER_WAIT/1e9 AS total_time_sec,
  SUM_ROWS_EXAMINED AS rows_examined
FROM performance_schema.events_statements_summary_by_digest 
ORDER BY total_time_sec DESC 
LIMIT 10;

• ?關(guān)鍵信息?：
  • query 字段可直接看到 SQL 操作的表（如 SELECT * FROM orders）。
  • exec_count 該SQL模式被執(zhí)行的次數(shù)
  • ?total_time_sec 該SQL模式所有執(zhí)行的總耗時(shí)（單位：皮秒，除以1e9轉(zhuǎn)換為秒；例如：SUM_TIMER_WAIT=1234567890000 → 1.23456789秒；識別最耗時(shí)的SQL模式
  • rows_examined 該SQL模式所有執(zhí)行中檢查的總行數(shù)；?例如?：1000000（表示這個(gè)SQL模式總共掃描了100萬行）?，用于識別全表掃描或索引效率低下的查詢

?方法 4：檢查表大小與索引狀態(tài)?

?查詢表空間占用?：

SELECT 
  TABLE_NAME,
  ROUND((DATA_LENGTH + INDEX_LENGTH)/1024/1024, 2) AS size_mb,
  TABLE_ROWS
FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'your_database'
ORDER BY size_mb DESC;

• ?大表（GB 級）?? 更容易因全表掃描導(dǎo)致 CPU 飆升。
• ?小表但高掃描頻次?：可能索引缺失或統(tǒng)計(jì)信息過期。

?檢查索引有效性?：

-- 查看表的索引情況
SHOW INDEX FROM your_table;

• 若 Cardinality（基數(shù)）遠(yuǎn)小于實(shí)際行數(shù)，說明索引可能失效，需更新統(tǒng)計(jì)信息：

ANALYZE TABLE your_table;

?三、針對性優(yōu)化措施?

?緊急處理?：

終止高消耗線程：

KILL <thread_id>;  -- 從 PROCESSLIST 獲取 thread_id

?索引優(yōu)化?：

• 為高頻查詢的 WHERE、JOIN、ORDER BY 字段添加索引。
• 避免索引失效：
  • 禁止對索引列使用函數(shù)（如 WHERE DATE(create_time) = ...）。
  • 避免隱式類型轉(zhuǎn)換（如字符串字段用數(shù)字查詢）。

?SQL 重寫?：

• 拆分復(fù)雜查詢（如將子查詢改為 JOIN）。
• 減少 SELECT *，僅返回必要字段。
• 分頁查詢優(yōu)化：用 WHERE id > last_id LIMIT n 替代 OFFSET。

?配置調(diào)整?：

增加臨時(shí)表大小，避免磁盤臨時(shí)表：

tmp_table_size = 256M
max_heap_table_size = 256M

調(diào)整 InnoDB 緩沖池（通常設(shè)為物理內(nèi)存的 70%）：

innodb_buffer_pool_size = 8G

?架構(gòu)擴(kuò)展?：

• 讀寫分離：將查詢分流到只讀副本。
• 分庫分表：對億級大表按業(yè)務(wù)拆分。

排查工具推薦?

注意?

• ?鎖競爭問題?：若 SHOW PROCESSLIST 顯示大量線程狀態(tài)為 Waiting for table lock，需檢查長事務(wù)或死鎖（information_schema.INNODB_TRX）。
• ?外部因素?：備份任務(wù)、批量數(shù)據(jù)維護(hù)也可能導(dǎo)致 CPU 短暫飆高，需結(jié)合操作日志排查。

以上就是MySQL CPU占用過高的排查指南的詳細(xì)內(nèi)容，更多關(guān)于MySQL CPU占用過高的資料請關(guān)注腳本之家其它相關(guān)文章！