核心是减少扫描和锁争抢。1. 确保WHERE条件使用索引，避免全表扫描；2. 分批更新大范围数据，降低对系统影响；3. 减少冗余索引和无意义赋值，提升写效率；4. 合理控制事务大小与提交频率，优化日志和并发。
UPDATE语句性能优化的核心在于减少扫描行数、提升索引效率、控制事务大小以及合理设计SQL结构。
1. 确保WHERE条件使用有效索引
UPDATE语句的执行效率高度依赖WHERE条件是否能命中索引。如果条件字段没有索引，MySQL会进行全表扫描，极大拖慢更新速度。
- 为WHERE中涉及的字段建立合适的单列或复合索引
- 避免在条件字段上使用函数或表达式，如
UPDATE table SET col = val WHERE YEAR(create_time) = 2024
，应改为直接比较时间范围
- 使用EXPLaiN分析执行计划，确认是否走索引
2. 避免更新过多数据一次性操作
大范围更新容易导致锁表时间长、日志文件暴涨、主从延迟等问题。
- 分批更新：通过LIMIT限制每次更新条数，例如
UPDATE table SET status = 1 WHERE status = 0 LIMIT 1000
，配合循环处理
- 结合主键范围分段更新，比如按id区间逐步推进，减少单次事务体积
- 在非高峰时段执行大批量更新，降低对业务影响
3. 合理设计索引与避免冗余写操作
不必要的索引更新会显著降低性能。
- 减少被更新字段上的索引数量，尤其是频繁修改的列
- 避免无意义的重复赋值，如
SET name = name
，即使值未变也会触发索引重建和binlog记录
- 只更新真正需要变更的字段，不要批量设置默认值或不变值
4. 调整事务与提交方式
在InnoDB引擎下，事务控制直接影响性能和并发。
- 大更新任务可显式分事务提交，避免长事务导致undo日志膨胀和锁持有过久
- 必要时临时关闭自动提交（autocommit=0），手动控制commit频率
- 确认binlog格式是否合理，ROW模式下大批量更新会生成大量日志
基本上就这些。关键点是让UPDATE快速定位到目标行、减少影响范围、降低锁争抢，并结合系统负载灵活调整策略。