UPDATE加LIMIT必须配ORDER BY，否则因存储引擎执行顺序不一致会导致漏更新或重复更新；应使用有索引的单调字段排序，避免无序扫描与性能断崖。
UPDATE加LIMIT必须配ORDER BY，否则会漏更新或重复
MySQL的UPDATE ... LIMIT N在没有ORDER BY时，执行顺序由存储引擎决定，不保证一致性。同一条件多次执行可能跳过某些行，或反复更新同一批——尤其在高并发写入场景下，status = 'pending'这类条件极易出错。
- 正确写法：必须用有索引的单调字段排序，例如
UPDATE orders SET status = 'processed' WHERE status = 'pending' ORDER BY id LIMIT 5000 - 错误写法：
UPDATE orders SET status = 'processed' WHERE status = 'pending' LIMIT 5000（无ORDER BY） - 如果
id不是主键或没索引，ORDER BY id反而触发filesort，拖慢每批执行时间——先确认EXPLAIN SELECT id FROM orders WHERE status = 'pending' ORDER BY id是否走索引
别用OFFSET分页式循环，改用游标+ROW_COUNT()判断结束
应用层写for i in range(0, total, batch)再UPDATE ... LIMIT 5000 OFFSET i是典型反模式：OFFSET越大扫描越深，第1000批可能要跳过99.9万行才找到目标，性能断崖式下跌。
- 推荐做法：用存储过程或脚本维护游标变量，每次取上一批最大
id作为下一批起点，例如UPDATE t SET x=1 WHERE id > @last_id AND status='pending' ORDER BY id LIMIT 5000 - 终止条件必须依赖
ROW_COUNT()，而不是预估总行数——因为过程中可能有新数据插入或状态变更 - 每批执行后立即
COMMIT，释放锁并刷binlog，避免事务堆积导致innodb_undo_tablespaces撑爆
主从同步链路上三个参数必须对齐
光靠分批没用，主库生成的binlog从库压根没法高效消费，照样卡住。以下三项不检查，调参全是白忙。
- 主库
binlog_format必须为ROW：STATEMENT格式在从库可能因函数、临时表等执行失败或结果不一致 - 从库开启并行复制：
slave_parallel_type = LOGICAL_CLOCK且slave_parallel_workers >= 4（建议设为CPU核数×0.75） - 从库
innodb_flush_log_at_trx_commit和sync_binlog需匹配：若设为0，sync_binlog也得设0，否则relay log写入快于磁盘刷盘，可能丢数据
WHERE条件字段没索引，分批就等于全表扫N次
每批LIMIT 5000看似小，但如果WHERE status = 'pending'没索引，MySQL就得全表扫描找前5000行——第一批次扫10万行，最后一趟可能扫800万行，耗时翻倍。
- 执行前务必跑
EXPLAIN UPDATE orders SET status='done' WHERE status='pending' LIMIT 1，确认type是ref或range，不是ALL - 加索引不是加完就完：
ALTER TABLE orders ADD INDEX idx_status (status)要评估对写入性能的影响，避免高频INSERT被拖慢 - 如果
status区分度极低（比如95%都是'pending'），单列索引效果有限，考虑组合索引如(status, id)并配合ORDER BY id
SLEEP(0.1)又受限于MySQL版本（5.7+才支持）。真正稳的方案，是把分批逻辑下沉到运维脚本里，用mysql -e逐条发，每批后sleep 0.1，既可控又不用改业务代码。 
