先说结论：我见过绝大多数团队的索引数量是"长"出来的，不是"算"出来的。加的时候有理由，减的时候没流程。而写放大的代价是隐性的、持续的、累积的——你永远不会收到一条"你的第 7 个二级索引今天又让 INSERT 慢了 0.3ms"的告警，但一年下来它就是真实的 P99 贡献项。
【背景】
我在一个写 QPS 约 12k、读 QPS 约 45k 的订单系统里待了三年。MySQL 8.0，单表 2.3 亿行，二级索引从最初的 3 个（业务唯一键 + 时间 + 状态）一路"长"到了 9 个。每一次加索引都有合理的业务理由——新报表、新风控规则、新对账逻辑。但到第 8、第 9 个的时候，没人再算过一笔账：
- 每次 INSERT 要维护 9 棵 B+ 树，写放大系数从 1 变成了 ~9（不含 undo log、redo log、binlog）
- 每次 UPDATE 如果命中 3 个索引列，要删 3 个旧 entry + 插 3 个新 entry，写放大翻倍
- Buffer Pool 里 9 棵树的非叶子节点常驻内存，在 16GB 实例上挤掉了约 18% 的热点数据页
这些代价不会在监控里单独出现，只会以"整体 INSERT P99 比理论值高了 2-4ms"的形式存在，然后被归因到"网络抖动"或"GC"。
【常见分歧 / 几种做法】
我观察到至少三种流派：
流派一：「索引越多越好，反正读比写重要」 典型场景：读 QPS 是写 QPS 的 10 倍以上，读路径是核心业务（搜索、列表、详情）。这种团队倾向于"能加就加"，觉得写放大是"可以接受的税"。问题出在：他们很少量化"第 6 个索引带来的读加速"和"第 6 个索引带来的写减速"的比值。
流派二：「索引是最贵的东西，能用代码算就别用索引」 典型场景：数据仓库、ETL 管道、批处理。这种团队倾向于把过滤逻辑推到应用层或 OLAP 引擎，OLTP 表上只留主键和 1-2 个业务唯一键。问题出在：一旦查询条件组合超过 3 个，应用层全表扫描的代价指数级上升，而且代码里的过滤条件很难被优化器看到（没法用索引跳跃）。
流派三：「靠 DBA 经验 + 慢查询日志事后补」 这是最常见的。索引是"出了问题再加"，而不是"设计时就算好"。结果是索引数量随业务迭代单调递增，从未被系统性审视。我见过一张表 14 个二级索引，其中 4 个的查询在过去 90 天的慢查询日志里出现次数为 0——它们还在吃写放大税。
【我的倾向与理由】
我的做法是把索引数量当成一个有预算的资源来管理，具体三步：
-
建索引前算写放大税：对每个候选索引，估算它会让单次 INSERT/UPDATE 多维护多少 B+ 树节点。公式很粗：
额外写 IO ≈ 索引数量 × 平均 B+ 树高度 × 页大小。不需要精确，但需要量级感。如果你的写 P99 预算是 5ms，而每个额外索引在 2.3 亿行表上贡献 ~0.4ms 的 B+ 树维护，那 9 个索引就是 3.6ms 的税——预算已经吃掉 72% 了。 -
建索引后 30 天必须回看：用
performance_schema.table_io_waits_summary_by_index_usage（MySQL）或pg_stat_user_indexes（PostgreSQL）拉出每个索引的index_reads / index_writes比值。如果某个索引 30 天内index_reads = 0或< 100，它就是"僵尸索引"，进入下线评审。 -
给索引数量设上限：不是"最多 5 个"这种拍脑袋数字，而是根据写 QPS / 读 QPS 比和 P99 预算反推。比如写 QPS 12k、P99 预算 5ms、每个索引税 0.4ms → 上限 = 5ms / 0.4ms ≈ 12 个（含主键），但考虑到 UPDATE 会放大，实际取 8-9 个。超过上限的新索引需求，要么走"应用层过滤 + 接受全表扫描"，要么走"拆表 / 分库"，要么走"加物化视图 / 读副本"。
核心原则：索引不是免费的读加速，它是用写吞吐和内存预算换的。 每次加索引都是一次资源分配决策，应该跟"要不要多开一个连接"一样有审批流程。
【想听大家怎么选】
特别想听几类场景的真实数据：
- 写多读少（金融交易、IoT 写入、日志采集）：你们二级索引一般控制在几个？有没有因为索引太多导致写 P99 超标、最后被迫砍索引的案例？砍的时候怎么验证"砍对了"？
- 读多写少（电商详情、内容平台）：你们索引数量到多少开始觉得"写税"开始影响整体 P99？有没有量过"第 N 个索引"的边际收益（读加速的 ms）和边际成本（写减速的 ms）？
- MySQL vs PostgreSQL：两个引擎的 B+ 树实现、索引维护路径、Buffer Pool 管理策略不同，同一个"9 个二级索引"在两边的实际代价差多少？有没有跨引擎迁移后索引数量需要重新评估的经历？
- 僵尸索引治理：你们团队有没有"索引下线"的正式流程？如果没有，是什么卡住了（业务方不敢确认、DBA 没权限、没有自动化检测）？
我猜多数团队的回答是"从来没量过"。如果是这样，那这个讨论帖的价值就在于：下次有人提"加个索引呗"的时候，你能把这笔账摊到桌面上。