慢查询治理的第一刀：先加索引、先改 SQL，还是先怀疑架构？

做了 8 年 DBA，慢查询治理几乎是日常。每次线上慢查询告警一响，我拉群拉人，第一句话经常被问的是"要不要加个索引"。但我越来越觉得，"加索引""改 SQL""改架构"这三条路各有各的适用边界，选错了代价不小。

我见过太多团队把"加索引"当万能药：索引越加越多，写入越来越慢、缓冲池越来越吃紧，最后一条查询快了、整库反而抖了。也见过团队一上来就谈分库分表、上归档，把一条 SQL 改好就能解决的事搞成了季度级大工程。

常见的分歧大致是三派：

• 索引派：能加索引解决的绝不改 SQL。索引是最小改动、最快见效、回滚也最容易，风险最低。
• SQL 派：很多慢查询是写法问题——回表、隐式类型转换、索引列被函数包裹、大 OFFSET 深翻页、不必要的子查询。先改 SQL 往往根本不用动表结构。
• 架构派：如果数据量、写入模式、查询模式本身就不匹配，加索引和改 SQL 都只是"给漏水的桶继续加水"，该上分区、分库分表或归档就得上。

我的倾向是"先 SQL、再索引、最后架构"，但有个硬前提：先搞清楚"慢在哪"——EXPLAIN / EXPLAIN ANALYZE 看执行计划，再看实际数据分布和统计信息，别凭感觉拍板。原因是这三者的"改动半径"完全不同：索引是治标，能让单条查询变快，但会反噬写入和存储；改 SQL 是治单条之本；架构调整是治全局之本，代价最高、回滚最难。所以我按"改动半径从小到大"排序：能用 SQL 解决的不动索引，能不动表结构就不重构，除非数据量和访问模式已经证明现有模型撑不住。

想听听大家：

1. 你们团队慢查询治理的"默认第一刀"是什么？加索引、改 SQL，还是先评估架构？
2. 有没有"加了索引反而更慢"或"该加索引却硬改 SQL 改崩了"的翻车经历？
3. 数据量到什么级别、什么访问模式下，你们会觉得"光靠 SQL 和索引已经不够，必须动架构了"？