加索引需权衡读写比，高频更新字段会引发多次b+树操作、锁争用、统计失真及页分裂；应避免热字段前置联合索引、慎用前缀/text/json索引，优先采用生成列哈希索引，并启用持久化统计。
频繁更新字段加索引会触发两次B+树操作
每次 UPDATE 修改该字段，InnoDB 必须先从索引中删除旧值对应节点，再插入新值节点——这不是“改一条记录”，而是两轮完整的 B+ 树查找 + 叶子页修改。如果该字段在多个索引里（比如单列 INDEX(status) 和联合 INDEX(status, created_at)），每轮更新就得同步刷所有相关索引。
- 常见错误现象：
Lock wait timeout exceeded、大量线程卡在Updating状态、innodb_row_lock_waits持续上涨 - 联合索引里把高频更新字段放前面（如
INDEX(status, user_id)）比放后面更糟：前缀变化导致整条索引路径重定位，页分裂概率飙升 - 实测 QPS 下降 30%～60%，延迟毛刺集中在 UPDATE 操作上
统计信息滞后会让优化器主动弃用索引
高频更新会让 Cardinality 快速失真，尤其像 status 这类只有几个取值的字段。优化器发现索引区分度暴跌（比如实际唯一值只有 3，但统计显示是 1000），就会判定“维护成本 > 使用收益”，直接跳过索引走 type=all。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 别只看
SHOW INDEX FROM t_order，重点查information_schema.INNODB_SYS_INDEXES.stat_n_diff_key_vals（更实时） - 小表或慢速累积更新容易卡在
innodb_stats_auto_recalc的 10% 触发阈值以下，手动ANALYZE TABLE又阻塞写入 - 真正有效的做法是开
innodb_stats_persistent = ON，搭配定期mysqlcheck --analyze
前缀索引和 TEXT 字段索引反而加重 DML 负担
很多人以为 INDEX(content(255)) 比全字段索引轻量，其实 MySQL 更新时仍需重新计算前缀值、刷新整个叶子节点，且因存储不紧凑更容易触发页分裂。对写入压力而言，它和 INDEX(content) 几乎没差别，但查询能力大幅缩水。
- 真正有效的替代方案是生成列 + 哈希：比如
content_hash CHAR(32) AS (MD5(content)) STORED，再建INDEX(content_hash) - JSON 字段同理：避免直接
INDEX(json_col)，优先用JSON_EXTRACT提取关键路径建虚拟列索引 - 日志表、评论表这类含长文本的场景，索引应聚焦在稳定过滤字段（如
created_at、user_id），而非内容本身
加索引前必须验证读写比是否真值得
不是“能不能加”，而是“不加就跑不动”。典型硬需求是：该字段虽高频更新，但更是核心查询条件，且没有其他过滤性更强的字段可用——比如订单表的 status，每秒 UPDATE 数百次，但运营后台每分钟执行几十次 SELECT ... WHERE status='shipped'。
- 判断阈值：单表每秒
UPDATE超过 50 次，且目标字段参与WHERE或SET，就要警惕 - 关键看读写比：如果
SELECT次数是UPDATE的 10 倍以上，且EXPLAIN显示不加索引时type=all，加了变ref或range，才值得扛写开销 - 务必检查冗余：已有
INDEX(status, created_at)就别再单独建INDEX(status)，否则写开销白给
