面试被问 MySQL 慢 SQL 怎么排查？看完这篇直接给面试官讲明白

做 Java 后端开发不管是自己练手的电商项目还是公司线上业务几乎都会被慢 SQL 毒打接口响应超时、数据库 CPU 直接打满甚至引发服务雪崩。几乎所有的项目中都会遇见慢SQL的问题相信大家在开发过程中踩过无数慢 SQL 的坑明明加了索引却不生效、分页查询越往后越慢、并发场景下领券接口直接超时。踩坑多了我沉淀出了一套从「发现问题」到「定位根因」再到「优化验证」的标准化排查流程新手也能一步步跟着操作面试的时候也能直接拿来当标准答案。这篇文章不会堆枯燥的底层原理只讲开发人员必须掌握的、可直接落地的排查方法看完你就能解决 90% 的慢 SQL 场景。首先讲解一下为什么会出现慢SQL一.为什么会出现慢SQL这里只列举场景的场景不常见的不在废话1.索引设计或使用不当在大部分的业务场景中索引设计或使用不当是慢 SQL 最常见的原因。1. 1根本没建索引最基础也最容易忽略的问题高频查询的字段WHERE、JOIN、ORDER BY、GROUP BY没有建索引导致 MySQL 只能做全表扫描索引分析详解第二部分如何分析慢SQL数据量越大越慢。场景举例优惠券系统里你写了SELECT * FROM coupon WHERE user_id 123但user_id没建索引每次查询都要扫遍整个优惠券表。1.2. 索引失效明明建了索引但 MySQL 优化器却不用常见失效场景索引字段用了函数 / 表达式比如WHERE YEAR(create_time) 2025MySQL 无法利用索引的有序性只能全表扫描-- 错误套函数索引失效 SELECT * FROM table WHERE YEAR(create_time) 2025; -- 正确用原始字段范围查询索引生效 SELECT * FROM table WHERE create_time 2025-01-01 00:00:00 AND create_time 2026-01-01 00:00:00;前缀模糊匹配比如WHERE order_no LIKE %123索引是按前缀排序的后缀模糊无法命中如果必须要查找后缀匹配的怎么办1.尽量把需要搜索的关键字段放在前缀比如订单号设计成123xxxx而不是xxxx123。2.如果数据量比较小不影响性能可以后缀匹配查找3.如果是大表可以在数据库中存储反转后的字段如reverse_order_id然后用reverse_order_id的前缀123%来查找order_id的后缀%123。也可以用ES等搜索引擎隐式类型转换比如user_id是VARCHAR类型却写了WHERE user_id 123数字MySQL 会自动给user_id加函数导致索引失效OR 条件包含非索引字段比如WHERE user_id 123 OR order_no 456如果order_no没索引整个查询都会退化为全表扫描。1.3. 索引设计不合理索引区分度太低给status只有 0/1/2、sex这类区分度极低的字段单独建索引MySQL 会觉得 “走索引还不如全表扫描快”直接放弃索引联合索引顺序不对不遵守最左前缀法则或者使用了范围查询使范围查询右边字段索引失效比如查询条件是WHERE user_id 123 AND create_time 2025-01-01但联合索引建的是(create_time, user_id)由于范围查询后的索引字段会失效这个索引只能用到create_time效率大打折扣INDEX idx_user_status_time (user_id, order_status, create_time) -- 只查第2位字段跳过第1位 user_id 索引失效 SELECT * FROM order WHERE order_status 1; -- 只查第1位 索引生效用到 user_id WHERE user_id 1001 -- 查第12位 索引生效用到 user_id order_status WHERE user_id 1001 AND order_status 1 -- 查全部 索引全效用到所有字段 WHERE user_id 1001 AND order_status 1 AND create_time 2025-01-01 -- 范围条件在前等值条件在后 索引只用到 create_timeuser_id 完全失效 SELECT * FROM order WHERE create_time 2025-01-01 AND user_id 1001;索引过多一个表建了十几个索引虽然查询快了但会严重拖慢INSERT、UPDATE、DELETE的速度还会占用大量磁盘空间。2.SQL 语句层面写法太随意2.1. 滥用SELECT *问题查询所有字段不仅会增加网络传输开销还会导致 MySQL 无法利用覆盖索引只查索引字段就能返回结果不需要回表性能大幅下降场景举例你只需要查用户的优惠券 ID 和金额却写了SELECT * FROM coupon如果表中有TEXT类型的大字段查询会更慢。2.2. 大偏移量分页问题比如LIMIT 100000, 10MySQL 会扫描 100010 行数据然后丢弃前 100000 行只返回最后 10 行数据量越大越慢场景举例苍穹外卖的订单列表页用户翻到第 1000 页接口直接超时。如果主键是自增连续可以使用覆盖索引子查询解决比如查找LIMIT 100000, 10就是先查找先查找第 100001 条数据的主键 ID → 再查 ID 大于它的 10 条数据-- 优化后速度提升 10~100 倍 SELECT * FROM order WHERE id (SELECT id FROM order ORDER BY id LIMIT 100000, 1) LIMIT 10;2.3. JOIN 表过多问题一次查询 JOIN 超过 3 张表MySQL 的优化器会很难选择最优的执行计划而且 JOIN 字段如果没有索引或字符集不一致性能会更差类似for循环嵌套影响性能场景举例为了查一个订单的详情你 JOIN 了订单表、用户表、商品表、优惠券表、地址表一共 5 张表查询耗时直接破秒。二.如何开启查看慢SQL1.开启慢SQL1.1临时开启重启 MySQL 后失效适合本地测试直接在 MySQL 客户端执行以下 SQL 即可-- 开启慢查询日志 SET GLOBAL slow_query_log ON; -- 慢SQL阈值执行时间超过1秒就记录可根据业务调整本地测试可设0.5s SET GLOBAL long_query_time 1; -- 可选记录没有使用索引的SQL提前发现潜在问题 SET GLOBAL log_queries_not_using_indexes ON; -- 查看慢查询日志存放路径后续直接打开这个文件分析 SHOW VARIABLES LIKE slow_query_log_file;1.2永久开启生产环境必用重启不失效修改 MySQL 的配置文件my.cnfLinux或my.iniWindows在[mysqld]模块下添加以下配置重启 MySQL 即可生效[mysqld] # 开启慢查询日志 slow_query_log ON # 日志存放路径 slow_query_log_file /var/lib/mysql/your-slow.log # 慢SQL阈值1秒 long_query_time 1 # 记录未使用索引的SQL log_queries_not_using_indexes ON2.查看慢SQL打开日志文件每条慢 SQL 都会附带核心统计信息重点看 3 个字段# Query_time: 2.315621 Lock_time: 0.000125 Rows_sent: 10 Rows_examined: 120560 SET timestamp1746589200; SELECT * FROM coupon WHERE user_id 123 AND create_time 2025-01-01;Query_timeSQL 总执行时间越长问题越严重Rows_sent最终返回给客户端的行数Rows_examinedMySQL 为了执行这条 SQL扫描的总行数。核心判断标准Rows_examined远大于Rows_sent说明 SQL 扫描了大量无效数据大概率是索引失效或者全表扫描必须优化。新手别图省事把long_query_time设得太小比如 0.1s否则会产生大量日志直接把服务器磁盘占满另外log_queries_not_using_indexes开启后会记录所有全表扫描的小表 SQL日志量会暴增生产环境建议按需开启。3.实时定位线上突发慢 SQL如果线上突然出现数据库 CPU 飙升、接口大面积超时不用等慢查询日志直接用这条 SQL 查看当前正在执行的所有会话-- 查看所有正在执行的SQL完整SQL用show full processlist SHOW PROCESSLIST;重点看这 4 列快速定位问题 SQL列名核心判断标准TimeSQL 执行时间单位秒数值越大越可疑优先处理State出现Copying to tmp table、Using filesort、Sending data大概率是慢 SQLInfo这里就是完整的 SQL 语句复制出来后续分析Command出现Sleep且 Time 极大的会话优先杀掉释放连接找到异常 SQL 后用kill 会话ID;直接杀掉会话先给线上服务止血再后续排查优化。三.如何分析慢SQL抓到慢 SQL 后不要上来就瞎加索引先在 SQL 前面加EXPLAIN关键字查看 MySQL 的执行计划这是定位慢 SQL 根因的核心没有之一。例EXPLAIN SELECT * FROM coupon WHERE user_id 123 AND create_time 2025-01-01;重点看这 5 个优先级最高的字段几乎可以定位到问题1. type访问类型判断索引用得好不好这个字段直接反映了 MySQL 是怎么查找表中的数据性能从好到差依次是systemconsteq_refrefrangeindexALL合格标准至少要达到range级别最优是ref及以上如果出现ALL说明是全表扫描必须优化常见值说明const主键 / 唯一索引的等值查询最快比如WHERE id 1ref普通非唯一索引的等值查询最常用比如WHERE user_id 123range索引范围扫描比如BETWEEN、、、INALL全表扫描性能最差绝对要避免。2. key实际用到的索引这个字段是 MySQL 实际执行时用到的索引名是判断索引是否生效的核心可以通过key和key_len可能会用到的索引判断有没有命中索引或者判断索引是否失效如果值为NULL说明没有用到任何索引要么没建索引要么索引失效了如果值和你预期的索引不一样说明 MySQL 优化器选择了其他索引大概率是索引区分度不够或者表统计信息不准确。3. rows预计扫描的行数这个值是 MySQL 预估的、为了找到目标数据需要扫描的行数越小越好。如果rows的值远大于你实际需要返回的行数说明索引设计不合理MySQL 扫描了大量无效数据性能必然很差。4. Extra额外信息藏着最多的坑这个字段会返回 SQL 执行的额外细节是避坑的核心重点看这几个值关键字含义 影响Using index【好现象】用到了覆盖索引不需要回表查询性能拉满优化的终极目标之一Using where存储引擎返回数据后在 Server 层用 WHERE 条件过滤扫描行数多的话要优化Using filesort【大坑】MySQL 无法用索引完成排序只能在内存 / 磁盘做文件排序数据量大时极慢Using temporary【大坑】为了执行 SQL 创建了临时表比如 GROUP BY 没有索引性能极差四、优化闭环优化后必须做的验证很多人改完 SQL、加完索引就完事了这是大错特错必须做验证确保优化真的生效没有引入新的问题。重新看执行计划用 EXPLAIN 重新执行优化后的 SQL确认type级别提升、key命中了正确的索引、rows大幅下降、Extra里的负面关键字消失实际执行看耗时真实执行 SQL对比优化前后的执行时间看是否符合预期回归业务场景确认优化后的 SQL业务逻辑完全正确没有出现数据错误上线后持续监控可以通过Prometheus Grafana或者Percona Monitoring and Management (PMM)上线后查看慢查询日志确认这条 SQL 不再出现同时监控数据库 CPU、接口响应时间确保没有影响其他业务。五.总结最后给大家总结一下慢 SQL 排查的完整流程一句话就能串起来先通过慢查询日志 /processlist 抓到慢 SQL → 用 EXPLAIN 分析执行计划定位根因 → 针对索引 / SQL / 表结构做优化 → 优化后完成验证形成闭环。其实慢 SQL 排查从来都不是靠瞎蒙而是靠一套标准化的流程。很多时候慢 SQL 的问题不是数据库的问题而是我们的开发习惯问题上线前不做 SQL 评审、不看执行计划、乱加索引才导致线上出现各种慢 SQL 问题。希望这篇文章能帮到大家也欢迎大家在评论区留言聊聊你在项目里遇到过的奇葩慢 SQL 问题我们一起交流避坑