真正拖慢大表UPDATE速度的是WHERE条件未使用但需维护的二级索引；MySQL每次更新都会同步修改所有相关索引，包括status、updated_at等高频更新字段的索引，导致写放大和I/O压力。
大表频繁 UPDATE 时，哪些索引会拖慢速度
真正卡住的往往不是主键或唯一索引，而是那些 WHERE 条件里没用上、但 UPDATE 语句却要维护的二级索引。MySQL 每次更新行，所有涉及该行的索引都要同步修改——哪怕你只改了一个不被索引覆盖的字段。
常见错误现象：UPDATE t SET status = 'done' WHERE id = 12345 执行变慢，而 id 是主键；查执行计划发现 Extra 里有 Using index condition 或大量 Rows examined，说明二级索引（比如 status、created_at）在隐式拖后腿。
- 先用
SHOW INDEX FROM t列出所有索引，重点关注非唯一、非主键、且字段更新频率高的索引（如status、updated_at） - 临时禁用某个索引测试：用
ALTER TABLE t DROP INDEX idx_status（注意备份，且确认业务逻辑不依赖该索引查询） - 如果删除后
UPDATE明显变快，说明该索引是瓶颈；可考虑改为延迟重建或业务层规避
MySQL 8.0+ 的不可见索引能替代“异步更新”吗
不能。不可见索引（INVISIBLE）只是让优化器忽略它，不参与查询计划，但它依然会在每次 INSERT/UPDATE/DELETE 时被实时维护——写放大照旧，I/O 压力不减。
使用场景有限：适合临时屏蔽某个索引做性能对比，或灰度下线前观察影响，但绝不是“异步索引更新”的解法。
-
ALTER TABLE t ALTER INDEX idx_updated_at INVISIBLE后，UPDATE仍会更新该索引数据页 - 真正降低写开销，得靠减少索引数量、合并冗余索引，或把高频更新字段移出索引前缀
- 若必须保留某字段索引，但更新极频繁，可考虑用生成列 + 函数索引（如
CREATE INDEX idx_status_day ON t ((DATE(created_at)))），降低更新粒度
UPDATE 太多时，索引设计的三个硬约束
没有银弹，只有取舍。索引不是越多越好，尤其对日均百万级 UPDATE 的表，每个索引都是写操作的固定成本。
- 单个索引字段数别超 3 个：复合索引字段越多，B+ 树分裂越频繁，页分裂导致随机写增多
- 避免对
TIMESTAMP/DATETIME类字段建单独索引：这类字段几乎每次UPDATE都变，索引更新开销接近全表扫描级别 - 不要为
UPDATE ... SET x = x + 1这类自增场景建索引：值变化无规律，缓存友好性差，且无法利用范围查找优势
真正可行的“类异步”折中方案
MySQL 本身不支持索引异步更新，但可以通过业务节奏和结构设计逼近效果：把“立刻可见”换成“秒级可见”，换 IO 压力为可控延迟。
- 把高频更新字段拆到独立小表（如
t_status_log），主表只存最终状态，用定时任务或触发器聚合更新 - 用
INSERT ... ON DUPLICATE KEY UPDATE替代UPDATE：InnoDB 对插入路径做了更多批处理优化，比纯更新更抗压 - 开启
innodb_change_buffering = all（默认已开），确保非唯一二级索引变更能缓冲在内存中批量刷盘——这是最接近“异步”的内置机制，但仅对非唯一索引生效
最容易被忽略的是：change buffer 不会缓存唯一索引、主键、或 INSERT 新行的索引更新。所以“高频更新 + 唯一约束”组合，基本无缓冲余地，只能靠删索引或改模型。
