救命！线上慢SQL把服务搞崩了! 5步实战排查，新手也能快速搞定

做后端、运维、DBA的朋友们，你们有没有被慢SQL坑过的经历呀？

查询接口卡了老半天，页面都加载不出来；日志刷满“SQL执行超时”，CPU飙升拖垮了整个数据库；对着SQL语句瞎改半天都没效果，反而越改越慢，太崩溃了！

现在的业务数据动辄千万级、亿级，一句烂SQL就能够拖垮整个服务，很多人陷入误区：觉得慢SQL优化是DBA专属，自己搞不定；或者搜一堆晦涩理论，实操起来一头雾水。

别慌！其实慢SQL优化根本不用死磕底层原理，掌握一套简单粗暴的排查步骤，小白也能快速定位问题、解决问题，再也不用被慢SQL拿捏了。

今天我就把慢SQL排查优化干货分享给大家，还会补充数据清理、CPU/内存占用分析的实用技巧，帮大家彻底摆脱慢SQL和数据库臃肿的困扰！

01  先避坑：90%的人都在犯的3个误区

排查之前，先和大家说说最容易踩的3个坑，很多人优化慢SQL没效果，是因为一开始就踩这些坑了：

1.误区一：慢SQL=加索引——这是最常见的误区，不是所有慢SQL都能靠加索引解决，盲目加索引，反而会拖慢插入、更新速度，尤其是高频写入的表，加太多索引只会雪上加霜；

2.误区二：上来就改SQL——没找到问题出在哪就瞎改SQL，这样只会白费力。比如明明是全表扫描导致慢，却调整字段顺序，这样怎么改也解决不了问题；

3.误区三：脱离场景谈优化——开发环境就几百条测试数据，SQL执行毫秒级，到了线上千万级数据量，直接卡成狗。忽略数据量和业务场景，再牛的优化技巧也白搭。

慢SQL优化的核心，从来不是“瞎改”，而是“先定位问题，再精准优化”，这压根才能快速见效。

02  实战排查5步，简单粗暴见效快

给大家以下5个简单步骤，不管是MySQL、PostgreSQL，还是其他主流数据库，都可以用，简单点一点、查一查，就能找到问题根源，立马提速。

第一步：先定位慢SQL

首先要找到哪条SQL在拖慢速度，有以下两种简单方法：

方法1（最直接）：数据库自带慢查询日志——打开数据库控制台，找到“慢查询日志”，开启后设置“慢查询阈值”（一般设1秒，超过1秒的SQL会被记录），等待10-30分钟，下载日志然后筛选出执行时间最长的前10条SQL并重点排查这几条；

方法2（更高效）：工具排查——用Navicat、DBeaver等常用工具，连接数据库后，找到“查询性能分析”，执行“显示运行中的SQL”，就能实时看到正在执行的SQL了，那些执行时间长、卡住不动的，就是我们要找的慢SQL。

重点：不用排查所有慢SQL，优先搞定“执行频率高+执行时间长”的，比如首页列表查询、高频接口的SQL，改完以后对整体性能提升最明显。

第二步：分析问题根源

找到慢SQL先不要急着改，看看它“为什么慢”：

1.  看“是否全表扫描”——如果执行计划里出现“ALL”，说明SQL在全表扫描，哪怕表只有100万条数据，也会很慢；

2.  看“索引是否生效”——如果执行计划里没有出现你建的索引名称，就说明索引没生效，要么是索引建错了，要么是SQL语句写法有问题；

3.  看“rows”数值——这个数值代表数据库需要扫描的行数，数值越大，执行越慢。

如果执行计划显示“ALL”，rows=1000000，说明这条SQL在全表扫描100万行数据，慢的根源就在这，然后就可以针对性优化了。

第三步：精准优化，改完秒提速

找到问题根源后的这3个简单方法，能够覆盖80%的慢SQL场景：

1.  优化索引（针对性加）——如果是全表扫描，就给查询条件里的字段加索引（比如where后面的id、name字段）；如果索引没生效，检查SQL写法（比如用了or、like '%%xxx'，会导致索引失效），这些都调整之后再重新测试一下；

2.  简化SQL语句（删冗余）——删掉SQL里没用的字段，不要用“select *”（查所有字段），只查需要的字段；删掉多余的join关联，非必要不关联多表，能拆分成两条SQL的，就别拼一条；

3.  限制查询条数（避免一次性查太多）——如果是分页查询，一定要加limit限制条数，比如“limit 0,20”，别一次性查几千、几万条数据，可以分页加载，这样更高效。

举个实操案例：原来的SQL是“select * from user where age > 18”，执行时间8秒，全表扫描100万行；给age字段加索引后，执行时间直接降到0.01秒，效果非常迅速。

第四步：测试验证

优化完别直接上线！一定要先在测试环境验证：

1.  用测试环境的大数据量（尽量保持线上一致），执行优化后的SQL，需要对比一下优化前后的执行时间，确认执行速度有提升；

2.  检查有没有影响到其他SQL——比如加了索引后，测试插入、更新操作的速度，避免因为加索引拖慢写入性能；

3.  模拟线上并发场景，比如用工具模拟1000人同时查询，确认SQL执行稳定，没有超时、卡顿。

第五步：上线监控

优化完上线后别以为就万事不用愁了，一定要做好监控，避免后续因为数据量增加、业务变更，再次出现慢SQL：

1.  可以开启数据库监控，实时关注SQL执行时间，设置告警（比如执行时间超过2秒就告警）；

2.  需要定期检查慢查询日志（每周一次），这样就能够及时发现新的慢SQL，可以提前优化；

3.  业务迭代时，新增的SQL一定要先做性能测试，避免新的SQL会拖慢整个数据库。

03  补充技巧：数据清理+SQL线程分析

很多时候，慢SQL不仅是SQL写法问题，还和数据库臃肿、CPU/内存占用过高有关——数据量日积月累，表体积过大，哪怕SQL写得再规范，执行速度也会变慢；还有更难被发现的是有些SQL悄悄占用大量CPU和内存。

我在这里给大家分享两个实用技巧，可以彻底解决这些问题：

技巧1：表分区+分区清理，让数据清理更高效

对于数据量超大的表（比如千万级、亿级数据的订单表、日志表），直接删除历史数据会很慢，还有可能锁表影响业务，给表增加分区，后续清理数据会更方便，还能提升查询速度：

1.  给表新增分区（以MySQL为例，按时间分区最常用）：打开数据库控制台，找到目标表，进入“表结构”页面，点击“添加分区”，选择类型为“范围分区”，按时间字段（比如create_time）划分分区（如每月一个分区），设置每个分区的时间范围；

2.  按分区清理数据：当需要清理历史数据（比如清理6个月前的日志数据），不用执行复杂的delete语句，直接在控制台找到对应分区，点击“删除分区”，可以瞬间完成清理，这种不会锁表也不会影响当前业务，可以帮我们翻倍效率；

分区字段建议选择常用查询字段（比如时间、地区），既能方便清理数据，还能提升按该字段查询的速度，一举两得。

技巧2：SQL线程分析，定位CPU/内存占用元凶

很多时候，数据库CPU、内存飙升，却找不到具体原因，其实是某些SQL线程长期占用资源，这时候我们需要做好SQL线程分析，就能精准定位元凶：

1.  查看SQL线程占用情况：打开数据库控制台，找到“线程管理”（或“进程列表”），筛选出“占用CPU/内存较高”的线程，重点查看的是线程对应的SQL语句、执行时长、占用资源百分比；

2.  分析并优化高占用SQL：对于占用CPU/内存过高的SQL，优先排查有没有存在全表扫描、索引失效、查询数据量过大等问题，按前面讲的3个优化方法调整，比如给查询字段加索引、简化SQL、限制查询条数；

3.  批量分析排查：如果不知道具体哪条SQL占用资源，可借助数据库自带的“性能分析”工具，生成CPU/内存占用报告，筛选出TOP10高占用SQL，批量优化。

很多企业、研发团队，没有专门的DBA，遇到数据库臃肿、CPU/内存飙升的问题，往往会不知道怎么办，不知道从哪下手。江苏立维可以帮大家精准分析——不管是排查哪些SQL占用CPU/内存，还是分析表分区设置、数据清理方案，专业DBA团队都会全程跟进，快速定位问题并高效解决。

04  实操总结：30秒快速判断+优化

如果线上突然出现慢SQL，服务卡顿，来不及一步步排查，可以用这个应急方法快速缓解：

1.  快速找到执行时间最长的SQL，先暂停该SQL的执行，避免继续拖垮数据库；

2.  检查是否全表扫描，如果是，要临时加索引；

3.  简化SQL，删掉冗余字段和关联，加上limit限制条数，重新执行，快速恢复服务

慢SQL优化其实没那么难，我们不用懂太多复杂的底层原理，只要掌握“定位-分析-优化-验证-监控”这5步，再加上表分区清理、SQL线程分析的技巧，就能搞定大部分数据库性能问题。很多人被慢SQL搞崩溃，不是因为不会，而是找不到正确的方法，盲目改会浪费时间还没有效果。