由 dawei 你是否发现，搜索响应越来越慢？查询偶尔超时，用户抱怨“搜不到”或“等太久”？问题未必出在代码或服务器，而可能藏在数据库的索引里——那些本该加速查询的“路标”，正在悄悄变成性能拖累。
索引不是越多越好。冗余索引会同时占用磁盘、内存和写入资源：每次INSERT、UPDATE、DELETE都要同步更新多个索引，导致写操作变慢；大量索引还挤占缓冲池，让真正关键的索引被迫换出内存，读性能反遭削弱。
更隐蔽的是“失效索引”。比如为user_id + status建了联合索引，却总只用status过滤——数据库无法高效使用该索引，查询依然走全表扫描；又如对JSON字段建立普通B-tree索引，却执行路径查询，结果完全无效。这类索引既不加速查询，又持续消耗维护成本。
AI设计稿，仅供参考
还有一种典型陷阱：过度依赖前缀索引。为长文本字段（如title）仅索引前20个字符，看似节省空间，但若大量标题前缀重复（如“报告：2024年Q1…”），索引选择性骤降，数据库仍需回表扫描数十甚至上百行，效率大打折扣。
索引碎片也在暗中作祟。频繁更新的表会使B-tree索引页分裂、数据页物理错乱，导致I/O次数上升。MySQL的INFORMATION_SCHEMA.STATISTICS或PostgreSQL的pg_stat_all_indexes能暴露低效索引，但更关键的是结合实际慢查询日志：哪些索引从未被命中？哪些被命中却未降低扫描行数？
解决它不靠删除所有索引，而靠精准诊断。定期运行EXPLAIN分析核心搜索语句，检查key列是否命中预期索引、rows是否明显偏高；用pt-index-usage或pg_stat_statements识别“零使用率”索引；对高频WHERE条件、ORDER BY和JOIN列优先保障覆盖度，而非盲目追加。
索引不是设好就一劳永逸的静态配置，而是随数据分布、查询模式和业务演进持续呼吸的活体结构。一次精简冗余索引，可能让搜索延迟下降40%；一个针对性重建，就能避免千万级数据下的秒级卡顿。性能优化的第一步，往往不是升级硬件，而是重新看清你的索引地图。