索引过多必然导致写入变慢，因每次增删改均需同步更新所有相关索引，引发B+树维护开销、磁盘与内存压力上升；应精简索引，聚焦高频查询，删除未用索引，避免低区分度字段单独建索引。
索引太多，写入变慢是必然的——每新增、修改或删除一行数据，数据库不仅要更新表本身，还要同步更新所有相关索引。索引不是越多越好，而是够用、精准、高效就好。
索引会拖慢INSERT/UPDATE/DELETE操作
每次写入时，数据库需维护B+树结构：插入新值要定位位置、可能触发页分裂；更新带索引字段要先查旧值再删旧条目、插新条目；DELETE则要从每个索引中定位并移除对应项。索引越多，这些额外开销越明显。
- 1个索引：写入约增加20%~30%耗时（取决于数据量和索引大小）
- 5个索引：常见场景下写入延迟可能翻倍甚至更高
- 含TEXT、JSON等大字段的索引，或前缀过长的字符串索引，维护成本更高
磁盘空间与内存压力双增长
每个索引都占用独立存储空间，且多数数据库（如MySQL InnoDB）把索引也加载进Buffer Pool。索引膨胀会导致：
- 更频繁的磁盘I/O（缓存命中率下降）
- 可用内存被索引挤占，影响查询缓存和排序缓冲区
- 备份体积增大、主从同步延迟升高（尤其DDL后批量写入）
优化建议：精简索引，聚焦高频路径
别为“以防万一”建索引。先看实际负载，再动手调整：
- 用performance_schema或slow query log分析真实查询模式，保留真正被用到的索引
- 合并重复索引（如已有(a,b)，就无需单独建(a)）
- 删除长期未被使用的索引（MySQL 8.0+ 可查sys.schema_unused_indexes）
- 对写多读少的表（如日志、消息队列），优先考虑覆盖索引或延迟建索引策略
不是所有字段都适合加索引
低区分度字段（如性别、状态码、是否删除标记）单独建索引效果差，还徒增负担。这类字段更适合：
- 作为联合索引的后置列（例如(tenant_id, status, create_time)）
- 配合条件过滤+排序场景再评估必要性
- 用位图索引（仅限支持该特性的数据库，如PostgreSQL、Oracle）替代
索引设计本质是读写权衡。写入性能下滑往往不是突然发生的，而是随着索引数量缓慢累积。定期审查、按需裁剪，比事后调优更有效。不复杂但容易忽略。
