写多读少场景下索引应“精而准”：聚焦高频查询字段，删减低频/冗余索引，用覆盖索引减少回表，分离读写流量，并调优索引类型与填充因子以降低写入开销。
写多读少场景下，索引不是越多越好，而是要“精而准”——重点保护高频查询字段，同时大幅降低写入路径的索引维护开销。
减少非必要索引，尤其避免组合索引滥用
每新增一个索引，INSERT/UPDATE/DELETE 都需同步更新该索引结构，写放大效应明显。在写多场景中，应严格评估每个索引的实际查询收益：
- 删除仅用于低频后台报表、或一年内几乎未被 WHERE/JOIN/ORDER BY 引用的索引
- 合并功能重叠的单列索引（如已有
(user_id)和(user_id, status)，通常只需后者） - 避免为写入频繁但极少用于过滤的字段建索引（如
create_time单独索引，若查询从不按时间范围精确筛选）
用覆盖索引替代回表，压缩查询对主键索引的依赖
当少量关键查询无法避免时，优先用覆盖索引满足其全部字段需求，避免访问聚簇索引（即主键B+树），从而降低读取压力和锁竞争：
- 例如：高频查询
SELECT order_no, status FROM orders WHERE user_id = ? AND status IN (?, ?)，可建INDEX idx_uid_status_cover (user_id, status, order_no) - 覆盖索引让查询完全在二级索引内完成，不触达主键页，减少IO与行锁持有时间
- 注意控制覆盖索引总宽度（字段数+长度），避免因过大反而拖慢写入
分离读写流量，用归档表或只读副本分担压力
将“写热”与“读冷”逻辑物理隔离，是写多场景最有效的架构级优化：
- 对历史数据建归档表（如
orders_2024_q1），主表只保留最近3个月数据，大幅缩小活跃索引体积 - 将统计类、分析类查询路由到只读从库，主库专注处理写入，避免读操作争抢缓冲池与锁资源
- 对强一致性要求不高的查询（如用户订单列表页的“最近10条”），可考虑异步双写至轻量级搜索表（如Elasticsearch）或物化视图
调整索引类型与填充因子（适用于PostgreSQL / SQL Server等支持配置的引擎）
部分数据库允许微调索引底层行为，缓解写入热点：
- 对高并发INSERT场景，适当调低B+树索引的
FILLFACTOR（如设为70–80），预留页内空间，减少页分裂频率 - 对仅用于范围扫描、极少更新的字段，可考虑BRIN索引（PostgreSQL）替代B-tree，极大节省空间与维护成本
- MySQL 8.0+ 可启用
innodb_fill_factor控制聚簇索引页填充率，间接影响二级索引写入效率
索引是把双刃剑，在写多场景里，克制比堆砌更重要；架构上做减法，比SQL里加Hint更治本。
