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

慢SQL出现时，很多人第一反应是"加索引"或者"改SQL"，但这往往治标不治本。

误区一：慢SQL = 加索引

盲目加索引会拖慢插入和更新速度，对高频写入的表尤其有害。索引不是越多越好，要加在刀刃上。

误区二：上来就改SQL

没找到根源就动SQL，效果有限，甚至可能引入新问题。

误区三：脱离场景谈优化

开发环境跑得飞快，线上却慢如蜗牛——数据量和业务场景不同，结论完全不一样。

核心原则：先定位问题，再精准优化。

实战排查5步

第一步：定位慢SQL

方法1（直接）： 开启数据库慢查询日志，设置阈值（通常1秒），让数据库自动记录超时SQL。

方法2（高效）： 用 Navicat、DBeaver 等工具的"查询性能分析"功能，实时查看正在执行的SQL。

优先处理"执行频率高 + 执行时间长"的SQL，这类SQL对系统影响最大。

第二步：分析问题根源

拿到慢SQL后，用 EXPLAIN 看执行计划，重点关注三个指标：

  • type 字段：出现 ALL 说明全表扫描，是大忌
  • key 字段：是否用上了索引
  • rows 字段：扫描行数越多越慢
EXPLAIN SELECT * FROM orders WHERE user_id = 12345;

第三步：精准优化

三个方法覆盖80%的场景：

  1. 优化索引 — 给查询条件字段加索引；注意 OR、LIKE '%xxx%' 会导致索引失效
  2. 简化SQL — 避免 SELECT *，只查需要的字段；删除多余的 JOIN
  3. 限制查询量 — 用 LIMIT 控制分页，避免一次性拉取大量数据

真实案例： 一条 SQL 原本执行8秒（全表扫描100万行），给 age 字段加索引后降至0.01秒。

第四步：测试验证

  • 在测试环境用接近线上的数据量验证优化效果
  • 检查对其他SQL的影响（插入、更新速度是否变慢）
  • 模拟线上并发场景，确认稳定性

第五步：上线监控

  • 开启数据库监控，设置告警（如执行时间超过2秒自动告警）
  • 每周定期检查慢查询日志
  • 新增SQL上线前必须做性能测试

进阶技巧

技巧1：表分区 + 分区清理

对千万级、亿级数据表，按时间字段做范围分区（如每月一个分区）。清理历史数据时直接删除对应分区，避免 DELETE 大量数据导致锁表影响业务。

-- 按月分区示例
ALTER TABLE logs PARTITION BY RANGE (YEAR(created_at)*100 + MONTH(created_at)) (
  PARTITION p202401 VALUES LESS THAN (202402),
  PARTITION p202402 VALUES LESS THAN (202403)
);

技巧2：SQL线程分析

定位CPU/内存占用元凶：

-- 查看当前正在执行的SQL
SHOW PROCESSLIST;

-- 查看详细执行状态
SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 5;

筛选出高占用线程，分析对应SQL是否存在全表扫描、索引失效、查询数据量过大等问题。

30秒应急方法

线上突然出现慢SQL，服务快撑不住时：

  1. 找到执行时间最长的SQL，评估是否可以 KILL 掉
  2. 检查是否全表扫描，若是则临时加索引（CREATE INDEX 在线加索引）
  3. 简化SQL、加 LIMIT 限制，快速恢复服务
  4. 事后再做根本性优化

掌握"定位 → 分析 → 优化 → 验证 → 监控"五步法，配合表分区和线程分析，可以解决大部分数据库性能问题。