大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
前面我们讲了rows和filtered的组合诊断，今天把视角拉高一点。
你有没有遇到过这种情况：每条SQL单独看都不慢，但系统整体就是响应慢。你花了一天优化了最慢的那条SQL，业务方说“没啥感觉”。你加班加了索引，系统负载反而高了。
这是因为你一直在“优化单条SQL”，而不是“优化整个系统”。
从“优化一条SQL”到“优化一个系统”，中间差的是三个思维层次的升级。今天把这三级拆开讲。
第一级：从“最慢的SQL”到“总消耗最大的SQL”
这个思维升级我们在“二八法则”那篇里讲过，但值得再强调一遍。
大多数人的优化逻辑是：打开慢查询日志，按执行时间排序，把最慢的那条拎出来优化。这个逻辑的问题在于——慢查询日志的阈值可能设高了。
如果long_query_time=1，一条0.3秒但每秒执行100次的SQL，根本不会出现在日志里。但它的日消耗是0.3 × 100 × 86400 = 259.2万秒，比任何一条慢查询都大。
正确的做法：开启performance_schema，查询events_statements_summary_by_digest表，按“累计执行时间”排序，找出总消耗最大的SQL，而不是单次执行最慢的SQL。
实操步骤：
-- 查看总消耗TOP 10的SQL
SELECT DIGEST_TEXT,
COUNT_STAR,
AVG_TIMER_WAIT/1000000000 AS avg_ms,
SUM_TIMER_WAIT/1000000000 AS total_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;
这条SQL让你直接看到“谁是真正的性能杀手”，而不是被慢查询日志的阈值挡住视线。
第二级：从“SQL视角”到“系统视角”
SQL调优做到一定程度，你会发现一个问题：单条SQL优化到极限了，系统还是慢。
这时候需要跳出“SQL视角”，进入“系统视角”——看整个数据库的负载特征，而不是看某一条SQL。
系统视角的核心指标：
| 指标 | 含义 | 正常值 |
| QPS/TPS | 每秒查询/事务数 | 与业务量匹配 |
| 连接数 | 当前活跃连接 | 不超过最大连接的70% |
| InnoDB缓冲池命中率 | 数据页在内存中的命中比例 | >95% |
| 临时表创建频率 | 每秒创建的临时表数量 | 越低越好 |
| 锁等待时间 | 事务等待锁的平均时间 | <10ms |
如果系统层面的指标出了问题，优化单条SQL是治标不治本的。
实操步骤：
-- 查看InnoDB缓冲池命中率
SHOW ENGINE INNODB STATUS\G
-- 查看命中率 = (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests
如果缓冲池命中率低于95%，说明内存不够用，加索引和改SQL都解决不了根本问题——需要增加innodb_buffer_pool_size。
-- 查看临时表创建频率
SHOW GLOBAL STATUS LIKE '%tmp%';
如果Created_tmp_disk_tables比例过高，说明很多查询在磁盘上创建了临时表，需要优化GROUP BY和ORDER BY的索引。
第三级：从“被动响应”到“主动预防”
最高级的优化，是不等问题发生就做好预防。
建立系统化的SQL健康管理流程：
- 常态化监控：每周跑一次
events_statements_summary_by_digest，看总消耗TOP 10的变化趋势。不要等业务投诉才去看。 - 建立基线：记录正常状态下的QPS、响应时间、慢查询数量。当指标偏离基线超过20%时触发告警，而不是等到系统卡死才响应。
- 上线前审查：重大SQL变更在上线前必须经过执行计划评审。不要等上了生产才发现慢，那时代价就大了。
- 容量规划：根据业务增长趋势，提前规划数据库规格升级、分库分表、读写分离等架构调整。等磁盘满了再扩容，那叫救火。
思维升级的落地路径
| 层级 | 思维 | 工具 | 产出 |
| 第一级 | 从“最慢”到“总消耗最大” | performance_schema | 找出真正的性能杀手 |
| 第二级 | 从“SQL视角”到“系统视角” | 系统指标监控 | 定位系统级瓶颈 |
| 第三级 | 从“被动响应”到“主动预防” | 监控+基线+容量规划 | 让系统平稳运行 |
总结
SQL调优做到最后，拼的不是技巧，是思维方式。从“优化一条SQL”升级到“优化一个系统”，需要经历三个层级的思维转变：
- 不要再盯着最慢的那条SQL，要盯着总消耗最大的那条
- 跳出单条SQL，看整个系统的负载特征
- 不等问题发生，主动建立预防机制
这三层思维，每一层都比前一层更难落地，但每一层带来的收益也是指数级增长的。如果你只停留在第一层，你永远是个“修理工”；当你走到第三层，你就开始像个“系统架构师”了。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
