写了十二年SQL才敢承认：索引不是银弹，是慢性毒药

十二年前，我写下第一条带索引的 CREATE TABLE，从此迷信上了这个银弹。直到三年前，一次大促前的慢查询风暴，把我从“索引万能论”的幻觉里彻底拽了出来。今天，我想坦白：索引不是性能的救世主，它更像一剂慢性毒药，在你不经意间，侵蚀着系统的写入能力、存储成本和架构弹性。

先别急着反驳。我见过太多团队，一遇慢查询就加索引，仿佛在玩打地鼠游戏。可你有没有算过，一个表上超过六个索引，写入性能会衰减多少？每次 INSERT、UPDATE、DELETE 都要维护所有索引的 B+ 树结构，这些额外的 I/O 和 CPU 开销，在低并发时无感，一旦流量洪峰到来，就是压垮数据库的最后一根稻草。去年某电商大促，一个订单表挂了十二个索引，写入 TPS 直接腰斩，临时下线三个冗余索引才勉强扛住——这场景，像不像给跑车装了一堆备胎？

更隐蔽的毒，在于索引对优化器决策的干扰。你以为加了索引就能走索引？MySQL 优化器可能因为统计信息过期、索引区分度低，直接全表扫描。而一个不恰当的复合索引，甚至会让原本高效的查询计划变慢。我曾排查过一个案例：某查询在 WHERE a=? AND b=? 上有索引 (a,b)，但业务又加了 (b,a)，结果优化器在两个索引间反复横跳，执行计划不稳定，延迟波动高达 300%。索引不是越多越好，而是越准越好——可“准”这个字，需要的是对数据分布、查询模式的持续洞察，而不是拍脑袋。

再说存储成本。很多人觉得磁盘便宜，索引占点空间无所谓。但云原生时代，存储 I/O 和内存才是真金白银。一个十亿行的表，每个二级索引动辄几十 GB，这些索引页会挤占 buffer pool，导致热数据被换出，缓存命中率下降。更别说备份恢复时间被拉长，DDL 操作锁表风险倍增。索引的维护成本，是随着数据量线性甚至指数增长的隐性负债。

那索引就一无是处？当然不是。问题在于，我们把它当成了银弹，而不是工具。真正的性能优化，应该从数据模型和查询模式入手：能不能用覆盖索引减少回表？能不能用分区表把索引维护局部化？能不能用读写分离，让从库承担索引密集的查询？甚至，能不能用列式存储或搜索引擎来替代部分索引场景？比如，把模糊匹配、多条件组合查询交给 Elasticsearch，把聚合分析交给 ClickHouse，让 OLTP 数据库专注事务处理，索引只保留最核心的几条。这才是架构层面的解药。

十二年 SQL 写下来，我最大的感悟是：索引是药，三分毒。用得好，它是加速器；用不好，它就是慢性毒药，慢慢消耗你的写入吞吐、存储预算和架构灵活性。下次想加索引前，先问自己三个问题：这个查询真的需要索引吗？现有索引能不能复用？有没有更合适的存储引擎或架构方案？别让索引成为你技术债清单上的又一个条目。