批量UPDATE慢的根源在于全表扫描、大范围锁和冗余日志，优化核心是快定位、少锁、分批处理：WHERE必须走索引（避免type=ALL），禁用字段函数，用范围查询替代；分批时按主键排序+LIMIT，加短暂停顿；可选INSERT…ON DUPLICATE KEY UPDATE替代；需关注索引维护、redo log配置、统计信息更新。
批量 UPDATE 慢，不是数据库不行，而是你没让数据库“轻松干活”——它在全表扫描、锁一大片、写一堆日志，还反复找行。优化核心就三件事：让它快定位、少锁、别一次干太多。
WHERE 条件必须走索引，否则就是全表扫描
这是最常见也最容易被忽略的性能断崖点。执行 EXPLAIN 看到 type=ALL，基本等于宣告这次 UPDATE 会慢到不可接受。
- 确保
WHERE中所有过滤字段已建索引，优先用联合索引，顺序按区分度从高到低，例如status（低区分度）和created_at（高区分度）组合时，建(created_at, status)比(status, created_at)更有效 - 禁止在
WHERE中对字段用函数，比如WHERE DATE(create_time) = '2026-01-01'会让索引完全失效；改用范围查询：create_time >= '2026-01-01' AND create_time - 避免隐式类型转换，比如
WHERE user_id = '123'（user_id是INT），MySQL 会放弃索引做全表转换
必须分批更新，单次别超几万行
一次性更新几十万行，不是快，是给数据库埋雷：undo 日志暴涨、行锁升级为间隙锁甚至表锁、Buffer Pool 压力飙升、其他业务接口直接卡死。
- 按主键或有索引的字段切片，推荐用
WHERE id BETWEEN ? AND ?，配合ORDER BY id确保边界确定，不重不漏 - 每批控制在 5000–20000 行之间，具体看单行数据大小和服务器配置；每批执行完立刻
COMMIT，释放锁和内存 - 别用
LIMIT offset, size分页更新（如LIMIT 100000, 5000），越往后越慢；改用游标式推进：WHERE id > last_id ORDER BY id LIMIT 5000 - 应用层加短暂停顿（如
Thread.sleep(50)），缓解 IO 和 CPU 瞬时压力，避免触发限流或 OOM
慎用替代写法：INSERT … ON DUPLICATE KEY UPDATE
当你的批量更新本质是“按唯一键覆盖新值”，且数据源可提前准备好（比如来自临时表、内存集合），这种写法往往比 UPDATE 更快——它省掉一次查找再修改的两步过程。
- 只适用于有主键或唯一索引的场景，例如同步用户状态、刷新配置缓存表
- MySQL 示例：
INSERT INTO users (id, name, status) VALUES (1,'A',1),(2,'B',1) ON DUPLICATE KEY UPDATE status = VALUES(status) - 注意
REPLACE INTO是先DELETE再INSERT，会导致自增 ID 跳变、外键级联删除等副作用，非必要不用 - 如果更新逻辑依赖原值（比如
counter = counter + 1），这种写法不适用，老老实实分批UPDATE
容易被跳过的细节：索引维护与事务控制
很多人调完索引、分完批就以为完了，但真正压测时还是慢——问题常出在这些“配角”上。
- 临时禁用非关键二级索引（如
ALTER TABLE t DROP INDEX idx_unneeded），更新完重建；宽表更新时，索引维护开销可能占总耗时 40% 以上 - 确认
innodb_log_file_size足够大，避免频繁刷 redo log；若业务允许短暂不一致，可临时设SET SESSION innodb_flush_log_at_trx_commit = 2 - 更新前用
SELECT COUNT(*)预估行数，避免盲目执行；记录每批的起止id和耗时，中断后能精准续跑 - 更新完成后立即执行
ANALYZE TABLE，否则后续查询可能因统计信息过期而选错执行计划
真正卡住的从来不是“要不要分批”，而是分批时没校验索引是否生效、没控制事务边界、没关掉不该存在的索引。这些地方一漏，优化就白做。
