SQL调优的“二八法则”：用20%的投入解决80%的慢查询
大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
你有没有过这种经历：花了一下午把一条跑30秒的SQL优化到0.5秒，成就感满满，结果业务方说“没感觉啊”。而你隔壁同事随手优化了一条0.3秒的SQL，业务方反而说“快了好多”。
这不是你的优化技术不行，是你优化的对象选错了。
有一条SQL每天跑1次，每次30秒，日消耗30秒。另一条SQL每天跑10万次，每次0.3秒，日消耗3万秒。你把第一条从30秒优化到0.5秒，节省了29.5秒。你把第二条从0.3秒优化到0.05秒，节省了2.5万秒。
这就是“二八法则”在SQL优化中的体现——20%的投入（找到正确的那条SQL）决定了80%的收益（整体性能提升）。
一、先算账，再动手：从“最慢的SQL”到“总消耗最大的SQL”
大部分人的优化逻辑是：打开慢查询日志，按执行时间排序，把最慢的那条拎出来优化。这个逻辑有两个问题：
问题一：慢查询日志的阈值可能设高了。如果long_query_time=1，0.3秒的SQL根本不会出现在日志里。但每秒执行100次，日消耗2.6万秒的SQL，它才是真正的性能杀手——只是从来没被你看到过。
问题二：忽略频率。一条跑得慢但很少执行的SQL，和一条跑得快但每秒执行100次的SQL，后者的总消耗可能比前者大几个数量级。
正确的做法是：先算总消耗，再排序。
总消耗 = 单次执行时间 × 执行频率
把这条公式记在脑子里。下次优化前，先找出总消耗最大的前10条SQL，而不是单次执行最慢的那几条。你会发现，排在前面的往往是那些你以为“很快”的SQL——只是因为它们跑得太频繁了。
怎么找到总消耗最大的SQL？
方法一：用pt-query-digest分析慢查询日志，按“总响应时间”排序输出。
方法二：开启performance_schema，查询events_statements_summary_by_digest表，直接获得每条SQL的累计执行时间和执行次数，算平均值和总消耗。
二、建立优化优先级矩阵：四象限法
把SQL按“单次耗时”和“执行频率”两个维度划分，画一个四象限：
| 象限 | 单次耗时 | 执行频率 | 优化优先级 | 策略 |
|---|---|---|---|---|
| 🔴 第一象限 | 高 | 高 | 最高 | 立即优化，收益最大 |
| 🟡 第二象限 | 高 | 低 | 中等 | 有空优化，收益尚可 |
| 🟡 第三象限 | 低 | 高 | 高 | 值得优化，积少成多 |
| 🟢 第四象限 | 低 | 低 | 最低 | 暂不处理，收益太低 |
第一象限的SQL是“双高”——单次慢、频率高。这种SQL是性能毒瘤，优化一条就能让整个系统脱胎换骨。如果你发现一条SQL每次跑3秒、每秒执行50次，日消耗就是1296万秒——别犹豫，放下一切优化它。
第三象限的SQL是“高频低耗”——单次看起来很快（0.1秒），但频率极高（每秒数百次）。这种SQL容易被忽略，但总消耗可能比第一象限还大。优化思路是“减少执行次数”而不是“加快单次速度”——比如加缓存、合并查询、改写业务逻辑避免重复查询。
三、实战案例：一条“很快但很忙”的SQL
某电商系统，用户反馈“加购物车变慢了”。慢查询日志里没有一条超过1秒的SQL。
用performance_schema查总消耗排序，发现排名第一的是一条SELECT user_id, name, avatar FROM users WHERE id = ?，平均执行时间0.05秒，每秒执行了300次。
日消耗：0.05 × 300 × 86400 = 129.6万秒。
根因：加购物车时，每次都要查一遍用户信息。但用户信息基本不变，根本不需要每次都查数据库。
优化方案：在Redis里缓存用户信息，缓存时间5分钟。从查询到命中缓存，应用层做了个简单的改造，加了几行代码。
效果：用户信息查询的数据库请求从每秒300次降到几乎为0，加购物车接口响应时间从200ms降到80ms，业务方说“流畅了”。
这条SQL单次只有0.05秒，如果按“最慢的SQL”去排，它永远不会被注意到。但按总消耗排，它排第一。
四、建立常态化监控机制：让数据告诉你该优化什么
不要等业务方投诉才去看慢查询。建立常态化的监控机制：
开启performance_schema：记录所有SQL的累计执行数据
每周跑一次总消耗排行：找出本周总消耗TOP 10
对比上周数据：发现新出现的“高频低效”SQL
建立优化清单：按四象限分类，确定本周优化目标
每周优化3条总消耗最大的SQL，坚持一个月，系统整体性能会有肉眼可见的提升——而且你会发现，真正需要动大手术的SQL其实不多，大部分都是这种“单个不慢但总量惊人”的SQL。
五、总结
SQL优化的核心不是“技术有多深”，而是“优先级对不对”。
不要只看单次耗时，要看总消耗（耗时×频率）
不要只优化最慢的，要优化总消耗最大的
用四象限法给SQL排优先级
建立常态化监控，让数据告诉你该做什么
把精力和时间花在对的地方，用最少的投入撬动最大的收益——这才是高效DBA和普通DBA的核心区别。下次打开慢查询日志，先别急着看最慢的那条，问问自己：“总消耗最大的那条SQL，我找到了吗？”
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~