做了这么多年后端最让我头疼的不是业务复杂度而是那些平时不吭声、一到高峰期就出来捣乱的慢SQL。数据库CPU飙高接口响应从几十毫秒涨到几秒钟前端页面一直转圈业务方着急忙慌来找你最后排查来排查去往往就是一条SQL在背后作妖。像是“页面卡死”“接口超时”“数据库CPU告警”这几种症状十次有八次都能落回到几条慢SQL身上。这篇文章我整理了十个从实际环境里排查过的经典案例业务字段做了脱敏但优化思路和踩坑过程都是原汁原味的。覆盖了订单查询、日志统计、报表聚合、分页列表这类最常见的业务场景每个案例我都会从表面现象开始讲清楚为什么慢最后给出具体可行的优化方案。不管你是后端开发、数据开发还是主要负责维护数据库的同学应该都能从中找到自己遇到过或者迟早会遇到的那条慢SQL。1. 认识慢SQL为什么一条查询能把整个链路拖垮1.1 慢SQL的直接特征和典型表象慢SQL的定义在不同团队里不一样但核心判别标准是一致的执行时间明显超出预期并且随着数据量增长或者并发升高耗时呈非线性恶化。很多团队把执行超过1秒的查询定义为慢查询这条线比较实用。一条用了全表扫描的查询在数据量只有十万的时候可能只要几十毫秒一旦数据涨到千万级几秒钟都算快的这就是为什么很多慢SQL问题都是“突然出现”的。典型表象通常是这样的白天业务高峰接口RT曲线开始往上爬数据库所在机器的CPU使用率居高不下磁盘IO和内存压力同步上升。更麻烦的是慢SQL占住了数据库连接不释放连接池被耗尽之后那些本身不慢的查询也排不上队了整个系统的症状会从“个别接口慢”演变成“所有接口都慢”。如果说普通慢查询是堵车那连接耗尽相当于整个停车场入口都被堵死了后面车再怎么好也进不来。1.2 慢SQL为什么会在高峰期爆发很多开发同学不理解为什么同一套代码白天慢、晚上快这背后的逻辑是数据库资源竞争和查询代价在不同负载下表现完全不同。一条SQL执行计划已经做得比较差比如使用了全表扫描它每条执行都要扫描几十万甚至上百万行。当并发只有个位数时数据库还能硬扛一旦并发到100每条查询都要抢CPU时间片、抢磁盘IO、抢内存缓存整体吞吐量就会急剧下降执行时间被成倍放大。这里可以拿餐厅做比喻。后厨只有一个厨师一个人点菜他应付得过来同时来二十桌客人每桌还都点需要现做的复杂菜后厨就彻底崩溃了。慢SQL就是那些“需要现做的复杂菜”平时少的时候看不出问题客人一多整个厨房都被拖死。优化慢SQL本质上是给厨师减负让他用最快的路径把菜做出来。1.3 定位慢SQL的基本流程我排查慢SQL一般遵循这样一套固定流程基本没踩过大的弯路。第一步是打开或者确认慢查询日志已经开启把阈值设到一个不干扰业务又能暴露问题的程度。第二步是从日志里把执行时间最长的几条SQL捞出来结合业务时间点跟监控系统的CPU、内存、IO曲线做一次对照确认问题真的出在SQL层面而不是被外部服务拖累。第三步是针对性看执行计划重点观察是否走索引、扫描行数有多少、有没有Using filesort或者Using temporary。第四步才是动手优化优化完必须重新执行并对比执行计划和实际耗时确认没有副作用。这套流程看着简单但很多同学会直接跳过第二步和第三步上来就凭着“经验”改SQL结果经常是把问题从另一个角度又引发一遍后面案例里我会讲到几个这样的典型翻车场景。2. 十个经典案例逐个拆解优化过程2.1 案例一字段上套了函数索引直接罢工某订单查询系统反馈按创建时间查订单的接口越来越慢。原SQL大概长这样SELECT order_id, user_id, total_amount FROM order_record WHERE DATE(create_time) 2025-03-20业务同学写这个SQL的想法很直接我只要某一天的数据。问题出在DATE(create_time)这个操作上它在索引字段上套了函数导致索引列的值必须先经过函数计算才能和常数比较。数据库优化器在这种情况下基本不会使用create_time上的索引因为索引里存的是原始时间值不是函数处理后的值走索引也得先把每个值算一遍还不如直接全表扫描省事。执行计划里也能印证这一点type字段显示ALLrows预估在百万级。优化方案是把函数去掉改成范围查询SELECT order_id, user_id, total_amount FROM order_record WHERE create_time 2025-03-20 00:00:00 AND create_time 2025-03-21 00:00:00范围改写之后走的是create_time索引扫描行数从百万级降到几百接口耗时从2.8秒降到60毫秒。这是一个特别经典的坑用函数让SQL读起来方便了但代价是整个索引失效。经验是任何时候在索引列上做运算、套函数、做隐式转换都在破坏B树的查找结构能避免就避免。2.2 案例二隐式类型转换让索引悄悄失效这个案例是后台管理系统的用户筛选功能出问题根据手机号精确查询用户信息接口偶尔超时。表结构里user_phone字段是varchar类型但前端传过来的查询参数被框架直接解析成了数字SQL就变成了SELECT user_id, user_name, user_phone FROM user_account WHERE user_phone 13800138000这个SQL最迷惑的地方在于开发同学建索引时很规范user_phone上是有唯一索引的自测的时候用字符串传参执行一切正常。上线后因为参数类型变化数据库要把varchar类型的索引值和数字类型做比较就需要把每个varchar值先转换成数字再进行比对。这个转换过程同样让索引失效。排查时EXPLAIN的type字段掉到了ALL关键信息在cast提示里面说明发生了字段类型转换。优化方案很简单把参数改成字符串类型让传参和字段类型保持一致SELECT user_id, user_name, user_phone FROM user_account WHERE user_phone 13800138000改成字符串传参后索引重新生效查询耗时从1.2秒降到10毫秒。这种事在真实环境里特别容易踩因为框架的自动类型转换、不同编程语言对类型的处理方式不一样都会让SQL里的参数悄悄变了个类型。排查时看到索引明明建了却不走第一反应就该检查字段类型和参数类型是否匹配。2.3 案例三深分页导致的越翻越慢分页列表遇到性能问题是家常便饭尤其是订单管理后台那种翻页特别深的功能。某运营后台的订单列表用户能翻到几千页翻得越慢越抱怨。原SQL简化后是SELECT order_id, user_id, total_amount, status FROM order_record ORDER BY id DESC LIMIT 1000000, 20这条SQL的问题在于偏移量越大数据库需要扫描越多的数据再丢弃。它会先读取前1000020行然后把前1000000行扔掉只返回最后20行。偏移到一百万之后哪怕走的是主键索引依然要把一百万行数据的位置都找出来耗时基本和偏移量成正比。优化方案是使用延迟关联先通过主键快速定位到需要分页的起始位置再去回表获取完整行数据SELECT o.order_id, o.user_id, o.total_amount, o.status FROM order_record o INNER JOIN ( SELECT id FROM order_record ORDER BY id DESC LIMIT 1000000, 20 ) t ON o.id t.id子查询只查询主键走索引非常快之后再用主键关联回去取完整数据回表操作只针对20条代价大幅度降低。实测这条SQL从原来的8.5秒降到了0.9秒。还有一种更彻底的办法是改成基于游标的分页也就是前端翻页时记住上一页最后一条的ID查询条件直接用WHERE id 上一页最大ID索引定位效率最高但需要前端配合改造后端的通用性弱一些。2.4 案例四JOIN关联字段忘记建索引两张大表关联查询慢这在报表统计里非常常见。某次遇到一个订单和用户关联的报表跑一次要几十秒业务方根本没法在页面等。SQL大致如下SELECT o.user_id, u.user_level, COUNT(*) AS order_count FROM order_record o INNER JOIN user_account u ON o.user_id u.user_id WHERE o.status 1 GROUP BY o.user_id, u.user_level从设计上看user_account.user_id是主键有聚簇索引。问题主要出在order_record.user_id上这个字段没有建索引。关联查询时数据库需要拿左表每一行的user_id去右表查找如果右表关联字段有索引查找走索引很快如果除了主键之外没有其他索引数据库就不得不对关联列做全表扫描。执行计划里能看到驱动表的扫描方式没问题但被驱动表的关联字段并没有利用索引。优化方案就是在order_record.user_id上加上普通索引ALTER TABLE order_record ADD INDEX idx_user_id (user_id)加索引之后被驱动表关联查询从全表扫描变成了索引点查整个查询耗时从25秒降到2秒以内。看似一分钟能解决的问题为什么没早点发现很多团队在建模阶段只关注了主键和唯一键忽略了对高频JOIN字段的索引覆盖这个代价在数据量小的时候看不出来数据量一大就立刻暴露。2.5 案例五临时表和文件排序带来的性能崩塌某内容社区做用户活跃统计按天统计每个用户的发帖数按发帖数倒序展示前100名。SQL是这样的SELECT user_id, COUNT(*) AS cnt FROM post_record WHERE create_time 2025-01-01 00:00:00 AND create_time 2025-03-01 00:00:00 GROUP BY user_id ORDER BY cnt DESC LIMIT 100这条SQL有聚合、分组、排序三个動作。执行计划里出现了Using temporary和Using filesort说明数据库生成了一张临时表来保存中间结果然后在临时表上做排序。问题根源在于WHERE条件过滤之后还需要按user_id分组而现有索引无法同时支撑范围过滤和分组排序的需求。优化方向是建立一个覆盖索引让范围查询和分组操作都在索引内部完成。我在post_record上建了一个联合索引ALTER TABLE post_record ADD INDEX idx_time_user (create_time, user_id)这个索引让范围条件先通过create_time定位然后group by user_id时索引本身就是有序的数据库能直接顺序读取聚合结果不再需要额外临时表。执行计划中Using temporary和Using filesort都消失了耗时从7.8秒降到1.2秒。这里有个设计心得GROUP BY和ORDER BY这样的操作如果能在索引列的顺序上保持一致性能收益非常明显。反过来如果分组字段和排序字段不一致临时表几乎不可避免。优化时也可以考虑走内存临时表把临时表大小调大一点但这只能缓解治本还得靠索引设计。2.6 案例六SELECT * 带来的隐性开销这个案例表面上看着不像慢SQL但它会从另一个层面拖垮系统。某数据后台导出一张日志表时SQL写的是SELECT * FROM operation_log WHERE user_id 10086 AND create_time 2025-01-01 AND create_time 2025-01-31operation_log表有40多个字段其中几个字段存储的内容特别大单行可能要占好几KB。查询本身逻辑没问题user_id和create_time都有索引但问题在于SELECT *会把所有字段都查出来。即使走索引也需要回表去取完整记录再加上大字段的传输开销网络带宽和内存都被白白消耗。尤其是在列表或者导出场景业务上根本不需要那么多字段。优化方案是按需取列只查询本次导出真正需要的字段SELECT user_id, action_type, ip_address, create_time FROM operation_log WHERE user_id 10086 AND create_time 2025-01-01 AND create_time 2025-01-31改完之后查询的数据量从每行几千字节降到几百字节同时我还给这个查询建了覆盖索引包含user_id、create_time以及需要返回的字段回表操作直接省略整体耗时从900毫秒降到120毫秒。SELECT *写起来确实爽但数据库开发和后台开发的职责边界要分清线上接口和报表查询建议都写明确字段。2.7 案例七OR条件让优化器放弃索引选择业务系统里常有“查状态为1或者状态为2的单子”这种需求。某营销系统的待办列表慢SQL有那么一股“想当然”的味道SELECT task_id, task_name, create_time FROM task_pool WHERE status 1 OR status 2 AND assignee_id 10001 ORDER BY create_time DESC这里还有个隐藏问题OR的优先级比AND低所以实际执行时被解析成了status 1 OR (status 2 AND assignee_id 10001)两条分支都能命中大量无关数据。因为条件里有OR优化器很难利用单个索引组合出高效的访问路径最终选择全表扫描。优化方案有两个方向。如果分支少且固定拆成两部分用UNION合并SELECT task_id, task_name, create_time FROM task_pool WHERE status 1 AND assignee_id 10001 UNION ALL SELECT task_id, task_name, create_time FROM task_pool WHERE status 2 AND assignee_id 10001但更推荐的方案是重新梳理业务语义发现其实就是要查“指定处理人的待办任务”那不如直接建联合索引ALTER TABLE task_pool ADD INDEX idx_assignee_status_time (assignee_id, status, create_time)改写后让assignee_id做驱动条件配合status过滤再用覆盖索引避免回表查询耗时从1.6秒降到80毫秒。这个案例的教训是遇到OR条件先检查它是否真的需要“或”以及优先级是否和预期一致OR除非每条分支都能独立走索引并且合并代价很小否则一般都不如改写为UNION或者重新设计条件结构。2.8 案例八大表COUNT(*)的假需求真开销这个案例来自一个数据看板页面要实时显示“今天的访问总数”。原来的实现特别简单SELECT COUNT(*) FROM access_log WHERE visit_date CURRENT_DATE()access_log表累计超过上亿行这个COUNT查询在非高峰期大约3秒高峰期数据量增长后甚至要到10秒以上页面直接被打挂。很多人第一反应是给visit_date建个索引不就行了。确实可以提升一些但COUNT(*)本质上还是要把所有符合条件的行都数一遍数据量大时无论怎么走索引计数成本都依然很高。我当时的判断是这个需求本身其实不需要精确到每一行。数字看板上的访问总数差那么几十几百业务方根本无感知但页面的响应速度影响很大。处理办法分两步第一步日常统计改为到一张独立的计数汇总表里查询每来一条访问记录就异步更新计数第二步保留精确查询能力但限制只在后台详情页使用并接受慢一点的返回。最终看板接口从不稳定的3秒加变成稳定的50毫秒以内。这类COUNT(*)场景特别典型业务要的往往是“趋势量级”而不是精确值开发同学硬生生把统计需求做成了精确计算成本翻了几十倍。经典优化路径就是三个字降精度。缓存计数、定时汇总、流水表维护冗余计数都是常用手段。2.9 案例九范围查询和排序组合导致索引失效某财务系统的流水查询按照交易时间过滤再按交易状态排序取前20条SELECT trade_id, account_id, trade_status, trade_amount FROM fund_flow WHERE trade_time 2025-03-01 00:00:00 AND trade_time 2025-03-31 23:59:59 ORDER BY trade_status, trade_id DESC LIMIT 20这里的问题是联合索引无法同时服务范围查询和排序。如果索引的第一个字段是trade_time范围条件能减掉大量行但按trade_status排序时索引已经因为前一个字段的范围扫描失去了顺序性数据库只能再做一次filesort如果索引的第一个字段是trade_status排序是省了但范围条件就只能变回全表扫描的等价物。最终我通过分析业务真正的使用习惯发现查询方实际上希望看到“这段时间内按交易状态分组的记录”那可以把查询改成“先拿状态再拿时间范围内的记录”建一个二段式联合索引ALTER TABLE fund_flow ADD INDEX idx_status_time (trade_status, trade_time)查询只过滤一个状态值时trade_status精确匹配能用上索引trade_time范围匹配在索引内部也是有序的排序不再需要filesort。实测耗时从4.5秒降到0.4秒。这个案例说明一个使用原则范围查询字段尽量放在联合索引的右侧精确等值条件放左侧才能最大化发挥索引的过滤和排序能力。2.10 案例十关联子查询的逐行扫描陷阱某商品系统要找出每个分类里价格高于平均价的商品列表第一次实现时用了比较直观的关联子查询SELECT sku_id, sku_name, category_id, price FROM product_sku p WHERE price ( SELECT AVG(price) FROM product_sku WHERE category_id p.category_id )SQL能跑出正确结果但商品表几百万行每个分类下面的SKU可能有上千个数据库每处理一行商品都要根据这一行的category_id去执行一次子查询计算该分类的平均价格。商品越多子查询执行次数越多整体代价是行数乘以分类数的乘积。执行计划里的DEPENDENT SUBQUERY就是这个问题最直白的提示。优化思路是把子查询先单独算好再和主查询做连接。先算每个分类平均价用临时结果再关联原表SELECT p.sku_id, p.sku_name, p.category_id, p.price FROM product_sku p INNER JOIN ( SELECT category_id, AVG(price) AS avg_price FROM product_sku GROUP BY category_id ) t ON p.category_id t.category_id WHERE p.price t.avg_price这样内层查询只做一次分类聚合外层和临时结果关联时也能走category_id索引整个执行时间从24秒降到0.8秒。关联子查询确实写起来结构清晰但在大数据量场景下的代价常常被忽略任何“外层每一行都重复计算一次”的写法都要谨慎。能用JOIN或临时表转化的优先转化。3. 排查慢SQL的高效手段日志、执行计划和剖面分析3.1 慢查询日志配置与采集不管优化手段多么熟练定位慢SQL的第一步永远是日志。慢查询日志是数据库自带的基础观测能力长期开启对你了解真实流量中的基线耗时非常有帮助系统默认可能是关闭的需要手动打开全局开关同时设好阈值SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1; SET GLOBAL log_queries_not_using_indexes ON;记住生产环境里把阈值设成1秒是个比较合理的起点太低会刷日志太高会漏掉真正有压力的查询。log_queries_not_using_indexes这个开关建议也打开这样那些即使跑得快但没走索引的查询也会被记录下来它们很可能是未来的慢SQL。日志拿到后聚合脚本要做的是按执行次数和总耗时排序而不仅是按单次耗时排序——很多慢SQL总量大但单条不引人注意它们累加起来才是压垮数据库的元凶。3.2 EXPLAIN核心指标怎么读EXPLAIN是每个后端开发必须熟练使用的工具它把SQL的执行计划摊开让你看。重点看四个指标type、key、rows、Extra。type这一列从好到差依次是const、eq_ref、ref、range、index、ALL见到ALL基本就是全表扫描key列表示实际用到的索引如果为NULL就要警惕rows是预估扫描行数差距数量级越大越危险Extra里如果出现Using filesort或者Using temporary意味着额外的排序或者临时表开销已经发生。很多人只会看一眼key觉得“走索引就是好的”这是不够的。所谓走索引也分回表和覆盖如果Extra显示Using index说明查询所需要的数据可以直接从索引中拿到连回表都省了这通常是最优路径。我一般会拿不同类型查询的EXPLAIN结果反复对比比如把执行计划打印出来索引字段、过滤条件、排序字段每一项都对齐慢在哪一步一目了然。3.3 用剖面分析找时间花在哪个环节EXPLAIN能看到执行计划但看不到时间细节。遇到“明明看起来走索引了但还是慢”的情况我建议开启数据库的剖面分析或者使用性能监控表。这类能力能列出一次查询在语法解析、表准备、执行、发送数据等各阶段分别消耗了多少时间定位到最耗时的阶段。实际排查中遇到过一种情况SQL执行计划非常漂亮type是refrows只有几百但接口还是慢。做剖面分析后发现时间基本集中在“发送数据”阶段原因是导出了几十MB的查询结果性能瓶颈在网络传输。如果只盯着执行计划看永远找不到这个原因。慢SQL排查不能只信EXPLAIN必须把日志、执行计划、剖面数据结合起来才能覆盖各个层面。4. 优化手段汇总从索引设计到SQL改写再到架构兜底4.1 索引设计原则最左前缀、覆盖索引、索引下推索引设计是慢SQL优化的核心手段我总结的几个原则基本能覆盖绝大多数场景。第一联合索引遵循最左前缀原则查询条件里如果用不到联合索引最左边的列整个索引大概率失效第二能用覆盖索引就不回表把查询需要的字段全部放进索引中可以跳过回表过程极大地减少随机IO第三索引下推能帮你在索引内部提前过滤尤其是索引用多个过滤条件时减少回表次数。举一个具体例子WHERE category_id 1 AND price 100如果索引是(category_id, price)存储引擎可以先在索引节点过滤掉不满足price 100的记录再回表拿数据。这个操作在旧版本数据库里要回表后再过滤现在很多版本已经能在索引遍历时完成效果就是少回表很多行。理解这些机制后你设计索引时就该去计算每个查询的扫描行数、回表行数用最小成本路径去支撑最高频查询。4.2 SQL改写技巧改写后逻辑不变、性能提升SQL改写是纯技术活核心原则只有一条结果语义完全不变执行路径大幅优化。常用的手段包括把条件中的函数运算去掉换成范围比较把关联子查询改成JOIN把OR条件拆成UNION把多个小查询合并成一个查询减少网络交互尽量不用SELECT *明确列出需要的列。改写时最忌讳的是为了性能牺牲正确性。比如把DATE(create_time) 2025-03-20直接改成create_time BETWEEN 2025-03-20 00:00:00 AND 2025-03-20 23:59:59这是等价的但如果改成create_time 2025-03-20就漏掉了当天的所有时间点结果就错了。改写完必须用同样的参数分别执行新旧两版SQL对比结果集的行数和字段值确认没有差异再上线。4.3 架构级兜底缓存、汇总表和生产降级有些SQL就算优化到极限还是慢比如案例八里的COUNT(*)统计以及那些必须扫全表做复杂聚合的报表。这时候不能死磕SQL本身要上升到架构层面解决。第一层是缓存把高频查询的热点数据放进内存读多写少的场景命中率很高第二层是汇总表用一个异步任务定期把明细数据聚合成汇总记录查询时直接读汇总结果第三层是读写分离把报表类的重查询打到只读副本上不占用主库的写性能。架构级优化的核心思路是把计算时间平摊到日常而不是让用户每次请求都重新计算一遍。数据量大的报表系统我基本不再直接查明细表而是先把明细数据导入宽表或数仓查询走汇总数据。用户看到的是秒级响应背后跑的是定时任务。架构层手段需要额外开发和数据同步成本但遇到真正的大数据量场景这往往是唯一能根治的路径。4.4 优化效果如何做验收优化不能靠“感觉快多了”来验收要有可量化的指标。我会把优化前后各执行三次以上取平均值做对比重点关注执行耗时、扫描行数、执行计划类型和是否有临时文件。如果有性能监控系统还要观察优化后在业务高峰期的响应时间分布确保没有把问题转移给别的环节。如果优化后只是执行时间从5秒变成4秒扫描行数依然是百万级这说明索引没有真正物尽其用只算是小修补。真正的优化应该是数量级的变化比如扫描行数从百万降到几百执行计划从全表扫描变成索引范围扫描filesort被消除。差一点的优化宁可不做改SQL是有风险的操作不能为了一个不痛不痒的结果就去动线上逻辑。5. 踩坑记录与我的实践经验5.1 测试环境与生产环境的天壤之别刚入行那几年我常犯一个错误在测试环境用几万行数据验证SQL没问题就认为生产环境也不会出问题。真实生产环境的数据量可能是测试环境的一千倍数据分布特征也完全不同。某次我优化完一条SQL在测试库执行11毫秒以为稳了结果上线后到了生产环境还是1秒钟原因是测试库里某个字段值分布很均匀而生产环境有严重的倾斜数据某一个大范围值占了几百万行索引选择的路径完全不同。后来我的经验是优化SQL前先看数据分布至少用几条统计SQL确认一下过滤字段的基数、NULL值的比例、范围条件命中数据的量级。生产环境的大表如果要跑验证查询务必避开高峰时段或者通过只读副本执行否则改SQL还没上线你自己那条探查SQL就成了新的慢SQL。5.2 索引建了执行计划怎么还是不走有段时间我特别困惑明明字段上建了索引EXPLAIN一看没走。后来排查多了才发现索引失去效力有很多诱因字段隐式类型转换、联合索引最左列没在条件里、条件里用了前缀模糊匹配LIKE %关键词、统计信息缺失导致优化器高估或低估了行数。还有一种很隐蔽的情况优化器发现走索引回表的成本比全表扫描还高它就会放弃索引这种在大范围查询时特别常见。所以建索引时不能只考虑“这个字段要建”还要想清楚查询条件对该字段的匹配方式。独立索引只能解决单列的等值或范围匹配多条件组合需要联合索引。优化器也是在执行成本之间做选择不是说写了索引就一定会用把索引设计当成普通的概率事件而不是银弹心态会平和很多。5.3 别一见慢SQL就加索引这是我想特别强调的一条。慢SQL的解决方案经常在SQL本身而不是非建索引不可。有些SQL明明是业务逻辑可以改写比如少查一次大表、分页逻辑换成游标、关联子查询改成JOIN非要用加索引硬扛反而占用了写入性能。索引不是免费的每一次插入、更新、删除都需要同步维护索引冗余索引越多写入成本越高还占内存。我自己习惯的做法是拿到慢SQL先做“四问”能不能避免这次查询能不能减少返回数据量能不能减少扫描行数能不能让执行计划更优这四问里只要有一问有了新的答案就不要急着加索引。一套好的优化动作永远是把读写成本和维护成本放在一起做综合评估而不是只看单条查询的降耗时。5.4 慢SQL优化之后还要做什么单条SQL优化完这件事才算完成一半。剩下的一半是要确保问题不复发。我会把优化过的SQL沉淀到一个团队内部的知识库里记录当时的表结构、数据量、现象、执行计划、优化方案和最终效果方便后来的人遇到相似问题直接参考。同时慢查询日志和监控告警要继续保持开启把慢SQL治理当成长期运转的机制而不是一次性的活动。另一个实操技巧是定期对高频查询做巡检不少SQL优化完之后随着数据量继续增长、业务规则变化可能过了半年又会变慢。我在实际维护中养成了每季度巡检一次的习惯把Top慢SQL拿出来再过一遍该合并的合并、该改写的改写、该加索引的加索引。慢SQL优化不是一锤子买卖而是一项需要持续投入的维护工作谁能在日常多花一点精力谁就不用总在凌晨被数据库的告警电话吵醒。
