背景
我做了 15 年大数据平台，前 5 年在 DBA 团队，后面一直做数据仓库与 OLTP 混合场景。一个观察：慢查询报警一响，开发同学（甚至不少 DBA）的第一反应就是"加个索引"。快、简单、当天下线、不用改代码。
但真实场景里，"加索引"远不是一个零成本动作。我在多个项目里见过：
- 一张 8000 万行的订单表，开发为了一个
WHERE status = 'PENDING' AND amount > 50000加了(status, amount)联合索引，写入 TPS 从 12k 掉到 9.6k（约 20% 写入放大），而这条 SQL 每天只跑 300 次； - 更隐蔽的：索引从 7 个加到 12 个之后，优化器在一条
JOIN + GROUP BY的查询里从走主键改为走某个二级索引，P99 反而从 15ms 涨到 48ms——因为二级索引回表后数据物理顺序乱了； - 还有"索引膨胀"：InnoDB 二级索引是聚簇索引的"影子"，每个二级索引叶子节点都存主键值。主键是 19 位 BIGINT 还好，换成 36 位 UUID 字符串，12 个索引 × 8000 万行 × 36 字节，光索引空间就多 3.5GB，Buffer Pool 命中率直接被稀释。
这些不是"理论上的成本"，是我在 3 个不同项目里实际踩过的坑。
常见分歧：三派做法
派 A：慢了就加，先治标再说 理由：业务等不起，改 SQL 要回归测试，加索引一条 DDL 就完事；"等优化器自己选"比"人工改写"风险小。 适用：查询是核心路径、QPS 高、业务方催命。
派 B：先分析再动手，索引是最后手段
理由：先 EXPLAIN ANALYZE（MySQL 8.0）看执行计划到底卡在哪步——是全表扫描、是排序溢出、还是 JOIN 策略选错？如果是 SQL 写法问题（比如 WHERE LEFT(name, 3) = 'abc'），加索引也白搭；如果是数据量问题，该分区就分区，该归档就归档。
适用：查询 QPS 低、数据量在涨、业务方不催。
派 C：加之前先算三笔账 这是我自己的做法，具体是：
- 写入放大比：这张表 TPS 多少？当前索引数多少？加一个索引，每行写入多一次 B+Tree 插入 + 一次主键回写（如果是非覆盖索引）。算一下"多出的写入耗时 / 这条查询省下的时间 × 查询频率"，如果比值 < 1，不加。
- 优化器选择概率：索引多了之后，优化器在多个可选路径里选错概率上升。特别是 MySQL 的 cost model 对
COUNT(*)、GROUP BY、子查询的估算经常偏乐观。加之前先ANALYZE TABLE，加之后跑一遍核心 SQL 的EXPLAIN，确认没把别的查询的路径搞乱。 - 空间与 Buffer Pool 压力：二级索引叶子节点存主键值，主键越长、行数越多、索引越多，Buffer Pool 里留给数据页的空间就越少。8000 万行 + 12 个索引 + 36 字节 UUID 主键，这不是小数目。
我的倾向
不是"不要加索引"，而是"加之前先算账"。
具体落地：
- 我们团队有一条约定：任何
ALTER TABLE ADD INDEX必须附一个 mini 文档（3 行就够），写清楚：①这条 SQL 的 QPS 和 P99 现状；②这张表的写入 TPS；③加完后核心 SQL 的 EXPLAIN 对比截图。不是形式主义，是逼自己把"写入放大"这笔账算一遍。 - 对于"每天跑 300 次、但每次 2 秒"的查询，我倾向于改 SQL（加 LIMIT、改 JOIN 顺序、用覆盖索引代替回表），而不是加新索引。改 SQL 的成本是一次性回归，加索引的成本是持续的写入税。
- 对于"每秒 200 次、每次 50ms"的核心路径查询，加索引是最便宜的方案，这时候别矫情。
核心原则：索引是"用持续成本换一次性收益"的工具，值不值得，取决于查询频率和数据量。
想听大家聊的
- 你遇到过"加了索引反而让别的 SQL 变慢"的案例吗？优化器误选是怎么发现的、怎么修的（
FORCE INDEX？改索引？optimizer_switch）？ - 你们团队对
ALTER TABLE ADD INDEX有没有审批流程？是 DBA 说了算，还是开发自己加？ - 对于"低频高延迟"的查询（每天跑几次、每次 5-30 秒），你的第一反应是改 SQL、加索引、还是直接上物化视图 / 预计算？
- 有没有人用
ANALYZE TABLE后执行计划反而变差的经历？（MySQL 8.0 的 histogram + optimizer 组合有时候确实玄学）
欢迎带具体场景和数据来聊，空谈"索引要看情况"的就不必了——我想知道你的"情况"到底是什么。
0赞
0收藏
0楼层