索引并非越多越好。过多索引会显著降低写入性能，增加磁盘空间与缓存压力，并干扰优化器选型；需通过系统视图识别冗余索引，结合写入场景采用延迟建索引、覆盖索引、分区局部索引及条件索引等策略优化，并持续监控迭代。
索引不是越多越好。当表上索引数量过多时，写入性能会明显下降，因为每次INSERT、UPDATE、DELETE操作不仅要修改数据页，还要同步更新所有相关索引结构。同时，索引本身占用磁盘空间，增加缓存压力，还可能干扰查询优化器选择最优执行计划。
写入成本为何随索引增多而上升
每新增一个索引，数据库就要为每一行写入操作维护一份额外的B+树（或哈希等）结构：
- INSERT：需在每个索引中插入对应键值，触发页分裂、合并等开销
- UPDATE：若修改了被索引列，所有涉及该列的索引都要更新；即使只改非索引列，聚簇索引（如InnoDB主键）变动也可能导致二级索引重排
- DELETE：需从每个索引中定位并移除对应条目，尤其范围删除时I/O放大明显
如何识别低效或冗余索引
很多索引长期未被使用，或功能重复，却持续消耗资源。可通过以下方式排查：
- 查information_schema.statistics或sys.schema_unused_indexes（MySQL 8.0+）定位零使用索引
- 用performance_schema.table_io_waits_summary_by_index_usage观察各索引实际命中次数
- 对比复合索引顺序：(a,b,c) 能覆盖 (a)、(a,b)，无需再单独建(a)或(a,b)索引
- 警惕“全字段索引”：如为WHERE a=1 AND b=2 ORDER BY c DESC建(a,b,c)，但实际查询常只过滤a，排序c——此时(a) + (c)可能更轻量
写入密集场景下的索引优化策略
面向日志、订单流水、IoT采集等高频写入表，应优先保障写入吞吐，再平衡查询需求：
- 延迟创建索引：批量导入前删掉非必要索引，导入完成后再重建，速度可提升数倍
- 用覆盖索引减少回表：把常用查询的SELECT字段加入索引INCLUDE（SQL Server）或作为索引后缀列（MySQL 8.0+函数索引+联合索引组合）
- 分区表配合局部索引：按时间分区后，只在活跃分区建索引，历史分区可停用或转为只读+无索引
- 考虑部分索引（PostgreSQL）或条件索引（MySQL 8.0+）：如CREATE INDEX idx_active ON orders(status) WHERE status IN ('pending','processing')，跳过大量已归档数据
监控与迭代建议
索引优化不是一劳永逸的事。业务逻辑变化、数据分布偏移、查询模式迁移都会让原有索引失效：
- 定期导出慢查询日志，用pt-query-digest分析TOP SQL的执行计划是否走了预期索引
- 关注Handler_read_next / Handler_write比值：该值持续走低，说明索引筛选率下降，可能需要调整索引列顺序或补充过滤条件
- 对核心大表，建立索引变更评审机制：新增索引必须附带explain结果、预估存储增长、写入压测数据
