慢查询治理先做索引还是先改SQL，答案不是固定的，而是要看当前瓶颈到底卡在索引设计上，还是卡在SQL本身的执行逻辑上先定位瓶颈，再决定动作顺序，才是唯一正确的治理路径。
为什么先做索引还是先改SQL会成为一个问题
很多DBA和开发者在处理慢查询时，第一反应是“加个索引试试”，但实际效果往往不理想：加了索引后查询还是慢，甚至比以前更慢，反过来，有人先改SQL，把子查询拆成JOIN，把OR改成UNION，折腾半天，发现执行计划根本没变化,因为瓶颈压根不在SQL写法上。
行业共识认为，慢查询的根因分布大致呈现“三三制”：约三分之一的场景是索引缺失或索引失效，约三分之一是SQL本身逻辑复杂或写法不合理，剩下三分之一则是数据分布、锁竞争、硬件资源等混合因素，既然根因不同,治理顺序自然不能一刀切。
判断瓶颈的钥匙，是执行计划和响应时间模型，你不需要猜，只需要看两个东西：执行计划里的访问方式（是Index Seek还是Table Scan），以及SQL的各个阶段耗时占比（是扫描耗时长，还是排序/连接耗时长）。
先看瓶颈类型，再定治理顺序
瓶颈在索引：先做索引，不改SQL
当执行计划显示大量Table Scan（全表扫描），或者明明有索引但Key Lookup（书签查找）次数爆炸，同时SQL语句的过滤条件本身是高效的（比如等值匹配、范围较小），这时候瓶颈很明确：索引没建好,或者索引设计不合理。
典型场景：一张订单表有500万行，查询条件是where user_id = 123 and status = 1，但只有主键索引，没有任何二级索引，此时执行计划必然是全表扫描，这时候你改SQL能改什么？把select 改成select id？把and改成and？毫无意义，正确的做法是立刻创建联合索引(user_id, status),让查询走索引查找。
操作步骤很简单：
- 用
EXPLAIN或SHOW PROFILE确认执行计划中的type字段是否为ALL或index。 - 检查
possible_keys是否为NULL，或者key没有使用你预期的索引。 - 根据
WHERE子句中的过滤字段、ORDER BY字段、GROUP BY字段，按等值在前，范围在后的原则设计联合索引。 - 使用
FORCE INDEX临时验证索引效果,确认后再正式添加。
这类场景下，先改SQL反而容易误伤，比如把原本简单的查询拆成多个子查询，会增加额外开销；或者把IN改成EXISTS，让执行计划变得更糟，索引是新建的资产，SQL是已有的逻辑，当资产缺失时,补资产比改逻辑更直接。
瓶颈在SQL逻辑：先改SQL，再考虑索引
另一类典型场景：SQL语句本身存在笛卡尔积、隐式类型转换、函数包裹索引列、多表关联顺序不合理、ORDER BY导致临时文件排序等问题，这时候即使索引存在,也发挥不了作用。
举个例子：where date(create_time) = '2026-01-01'，如果create_time是索引列，但用date()函数包裹后，索引直接失效，这时候你先加索引也没用，因为函数让索引列失去索引特性，正确做法是改写SQL为where create_time >= '2026-01-01' and create_time < '2026-01-02'，同时保证create_time上已有索引。
再比如一个经典慢查询：三张大表关联，其中一张表是驱动表，但由于ON条件里没写小表驱动大表，导致扫描行数几何级增长，此时即使给每张表都加上索引，优化器也可能选错执行计划，你需要手动调整JOIN顺序，或者用STRAIGHT_JOIN强制指定顺序,再观察效果。
改SQL的优先级通常高于加索引,因为：
- SQL是消耗资源的直接来源，改完能立即减少扫描行数和内存/临时表使用。
- 索引是额外的存储和写放大成本,能用SQL逻辑解决就不要用索引扛。
- 优化的SQL往往能让现有索引复用，避免新增索引带来的插入、更新性能损耗。
混合瓶颈：按“扫描成本 vs 计算成本”拆解
有时候执行计划看着没问题，索引也用上了，但查询还是慢，这种情况下，瓶颈可能藏得更深可能是返回行数过多（比如select 返回几千行），也可能是排序/分组消耗过大（order by走文件排序），或者连接缓冲不足。
此时需要拆解成本模型，业内专家指出，一个慢查询的优化判断可遵循如下顺序：先检查请求的数据量是否合理，再确认扫描行数是否接近返回行数，最后分析CPU/IO时间主要花在哪个算子，如果扫描行数多但返回行数少，那往往是索引选择性差，优先优化索引；如果扫描行数少但返回行数多，那优先改SQL（限制列、加分页、做聚合下推）；如果扫描和返回都正常，但Extra列出现Using temporary或Using filesort，那要改SQL（去掉ORDER BY的隐式转换，或者把排序提前到子查询内）。
举一个实际例子：某个报表查询，where type = 2 order by create_time desc limit 20，type字段有索引，但create_time没有索引，执行计划会走type索引，但排序需要做文件排序，此时你加索引(type, create_time)能解决排序问题，但也可以改写SQL，让排序在子查询中预先完成后再关联其他表，哪个更好？如果表行数不多，加索引更简单；如果行数上亿，加索引会导致索引维护成本高，改SQL更优,所以还是要回到瓶颈定位。
如何用工具快速判断瓶颈在哪
拿执行计划说话
MySQL系数据库用EXPLAIN，PostgreSQL用EXPLAIN ANALYZE,核心看四个字段：
type：从system到const、eq_ref、ref、range是好的，出现index或ALL就要警惕。rows
：预估扫描行数，如果比实际数据量小很多，说明索引生效；如果接近全表行数,说明索引用不上。
Extra：出现Using filesort、Using temporary、Using join buffer，说明排序、分组或连接部分逻辑有隐患。key：实际使用的索引，如果为NULL，但possible_keys有值，说明优化器没选正确索引，可能需要ANALYZE TABLE更新统计信息。
看慢查询日志和状态变量
慢查询日志记录了实际执行时间和扫描行数，拿到慢日志后，重点对比同类型查询的执行计划差异，比如两条SQL条件相似，一个走索引一个不走，那问题可能出在数据分布不均匀上，此时需要单独处理“卡点值”（比如某个user_id的数据量特别大），这属于极端数据倾斜，加索引和改SQL都无法根治，只能代码层面做“截止条件”或“分片查询”。
还可以用SHOW GLOBAL STATUS LIKE 'Handler_read%'查看索引使用效率，如果Handler_read_rnd_next值很大，说明有大量全表扫描，索引没起作用；如果Handler_read_key值高，说明索引使用频繁,这些指标能辅助判断瓶颈倾向。
不同数据库场景下的治理策略差异
MySQL InnoDB：辅助索引和回表是重点
InnoDB的聚簇索引结构决定了辅助索引需要回表，查询如果返回列不在索引中，就会产生回表操作。覆盖索引是解决回表的最佳手段，当慢查询表现为Extra里有Using index condition但仍有大量Key Lookup时，优先考虑把查询列并入索引，而不是改SQL，比如select name from users where age > 20，如果已有(age)索引，但name需要回表，改SQL不能减少回表次数，应该把索引改为(age, name)。
PostgreSQL：索引类型和统计信息要细看
PG的优化器相比MySQL更“智能”，它会根据统计信息自动选择是否走索引，如果你发现PG对某条SQL走了全表扫描而且很快，那可能确实是全表扫描更快（比如小表），这时候先别急着加索引或者改SQL，先检查default_statistics_target是否过低，或者ANALYZE执行时间是否太久,统计信息不准也会导致执行计划偏差。
SQL Server / Oracle：参数嗅探影响不可忽视
在这些商业数据库中，同一个SQL因为参数不同，执行计划可能在“索引查找”和“全表扫描”间切换，因为优化器会基于第一个传入的参数生成计划，后续参数不匹配时便退化，这种情况属于“计划不稳定性”，先改SQL（比如用OPTION(RECOMPILE)或OPTIMIZE FOR UNKNOWN）比加索引更优先，因为索引本身没问题,问题在于优化器的参数假设。
实操：一个完整的慢查询治理顺序清单
当你接到一个慢查询工单，建议按以下步骤执行,不要跳过或颠倒：
- 第一步：记录原查询的响应时间、扫描行数、返回行数,作为基线数据。
- 第二步：查看执行计划，识别访问类型和额外操作
，确认是否存在全表扫描、文件排序、临时表。
- 第三步：用
PROFILING或PERFORMANCE_SCHEMA定位耗时占比高的阶段，如果Sending data阶段耗时长，说明扫描+传输是主因；如果Sorting result耗时长,说明排序是主因。 - 第四步：判断瓶颈属性：如果是索引缺失导致的全表扫描，且SQL过滤条件可索引，那立刻建索引；如果是函数包裹列、类型匹配出错、JOIN顺序错乱，那先改SQL；两者都有，先改SQL后用
EXPLAIN复核,再决定是否补索引。 - 第五步：变更后验证，对比执行计划是否变为更优的访问方式，同时观察CPU和IO负载是否下降，如果加载索引后，插入性能明显下降（比如某业务写入频繁）,就要权衡是否用SQL改写代替索引。
Q&A：慢查询治理的常见追问
加了索引后查询反而更慢，是为什么？
因为优化器选择索引后，如果索引选择性差（比如status=1对应的行数占全表50%），就会产生大量回表和随机IO，反而比全表扫描的顺序IO慢，此时应该考虑覆盖索引或复合索引让索引包含所有需要的列，或者直接改SQL加FORCE INDEX强制走更适合的索引，如果数据分布极度倾斜，可能需要调整查询逻辑,比如把高频值单独处理。
改SQL和加索引可以同时做吗？
可以，但建议分步验证，先改SQL，比如去掉无用的列、拆分复杂关联、消除函数包裹，然后看执行计划变化，如果仍存在索引缺失，再补索引，同时改的话，你无法判断是哪一步起效，也无法回滚到最优状态，更好的方式是使用影子库或预发布环境，先在新环境测试组合效果，再上线，另一种例外：当索引缺失且SQL本身有多余操作时，同时做能节省一次发布周期,但前提是你已经充分理解瓶颈构成。
慢查询治理的优先级是否应该先看数据量大小？
数据量是重要参考，但不是决定优先级的第一要素，一张100万行的表如果索引设计合理，查询能在1毫秒内完成；一张10万行的表如果SQL用错连接方式，也可能跑出10秒，真正决定优先级的是瓶颈所在层：存储引擎的IO层、优化器的决策层、还是SQL的表达式层，先用执行计划定位，再结合数据量评估后续风险，如果数据量在未来三个月会增长十倍，那么即使当前索引能解决问题，也要考虑SQL是否足够高效,避免将来索引无法支撑。
慢查询治理不是“先加索引”或“先改SQL”的单选题，而是先诊断瓶颈、再按瓶颈选择动作的判断题，索引解决的是“访问路径”问题，SQL解决的是“请求逻辑”问题，路径不通就修路径，逻辑太绕就改逻辑，两者都乱就按照先SQL后索引的顺序逐步验证，因为SQL改写通常能降低对索引的依赖，而索引只是辅助手段，每一次治理后，都要重新对比执行计划和响应时间,让数据告诉你下一步该做什么。