主库写入频繁时，高更新频率字段上的普通二级索引（如status、updated_at）、复合索引顺序不当、全文/空间/前缀索引会显著拖慢INSERT/UPDATE性能。
主库写入频繁时，哪些索引会拖慢 INSERT/UPDATE 性能
主库承担所有写操作，每多一个索引，就多一次 B+ 树的插入/分裂/回写开销。尤其当字段更新频繁、值随机性强（如 UUID、created_at），索引维护成本会指数级上升。
常见错误现象：SHOW PROCESSLIST 中大量 updating 状态；innodb_row_lock_waits 持续升高；写入吞吐卡在 500 QPS 上不去，但 CPU 和磁盘 I/O 并不高。
- 避免在高更新频率字段上建普通二级索引，比如
status（订单状态每分钟变多次）、updated_at - 复合索引中，把写入变动少的列放前面，变动多的放后面（例如
(tenant_id, status, updated_at)比(updated_at, tenant_id, status)更友好） - 用
DROP INDEX临时移除非关键索引做压测对比，观察innodb_data_writes和平均延迟变化 - 全文索引、空间索引、前缀索引（
name(10)）在写入路径上同样有开销，别只盯着 B-tree
从库读请求带 ORDER BY 或 GROUP BY 时，怎么让索引真正生效
从库查询往往更复杂：分页、聚合、多条件排序。但很多索引在从库“看起来存在”，实际执行计划里却走不了——因为优化器发现数据分布和主库不一致（复制延迟导致统计信息滞后），或索引顺序和查询谓词不匹配。
使用场景：后台报表页查 SELECT * FROM order WHERE shop_id = ? AND created_at > ? ORDER BY pay_time DESC LIMIT 20，明明有 (shop_id, created_at) 却用 Using filesort。
- 强制按查询字段顺序建联合索引，且范围条件字段必须放在等值条件之后（
(shop_id, created_at, pay_time)✅，(shop_id, pay_time, created_at)❌） - 从库开启
innodb_stats_persistent = ON并定期运行ANALYZE TABLE，避免因复制延迟导致的统计信息陈旧 - 避免在
ORDER BY字段上用函数，如ORDER BY DATE(created_at)—— 这会让索引失效，改用范围查询 + 覆盖索引 - 如果读请求固定走某几个维度，考虑在从库单独建冗余索引（主库不建），例如只为从库加
(user_id, status, created_at)支持用户中心查询
READ COMMITTED 隔离级别下，唯一索引冲突为什么还会锁全表
主库用 READ COMMITTED 是为了降低锁粒度，但很多人忽略了：唯一索引的重复键检查仍会触发 next-key lock，尤其在插入不存在的值时，InnoDB 会锁住“间隙”，而这个间隙可能覆盖大片范围。
典型错误现象：并发插入 email 唯一索引时，出现 Deadlock found when trying to get lock；或者看似无关的两条插入语句互相阻塞（比如插 a@b.com 和 c@d.com 却锁住了中间所有邮箱区间）。
- 确认是否真需要唯一约束——有时业务层去重 + 应用层幂等比数据库唯一索引更轻量
- 把唯一字段设为自增主键或紧凑类型（如
BINARY(16)存 UUIDv4），减少间隙大小 - 避免在字符串唯一索引上用前缀（
email(32)），前缀越短，间隙锁覆盖范围越大 - 监控
innodb_row_lock_time_avg和innodb_deadlocks，一旦飙升，优先检查唯一索引的插入热点
从库加索引会不会影响主从延迟
会，而且影响方式很隐蔽：不是“加索引”本身慢，而是加完后主库的写操作突然变慢，从而拖累整个复制链路。因为从库索引变更后，主库的 UPDATE 日志在从库回放时，要同步更新多个索引树，而这些索引在主库并不存在。
性能影响：从库 Seconds_Behind_Master 在 DDL 后缓慢爬升；Replica_SQL_Running_State 显示 Updating main table 时间变长；innodb_buffer_pool_wait_free 上升。
- 从库加索引前，先在主库用
EXPLAIN UPDATE ...模拟对应写语句，看是否引入新索引扫描 - 避免在从库建“仅用于读”的宽索引（如
(a,b,c,d,e)），优先用覆盖索引 +SELECT ... FOR UPDATE替代 - 如果必须加，用
ALGORITHM=INPLACE+LOCK=NONE（MySQL 5.6+），并避开业务高峰 - 上线后盯紧
SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos增速，比对主库master_log_pos，确认延迟是否由索引引起
最易被忽略的一点：从库索引字段如果有 NULL 值，默认会额外占用一个字节标记位，批量更新时这个开销会被放大，尤其在千万级大表上——别只看索引结构，也得看数据实际分布。
