update无where会锁全表，因innodb升级为聚簇索引记录+间隙锁；须用explain验证索引有效，分批更新应按主键范围切割并落库日志确保原子性、可观测与可恢复。
UPDATE 语句没加 WHERE 条件，直接锁全表
MySQL 的 UPDATE 在未命中索引或没写 WHERE 时，InnoDB 会升级为表级锁（实际是锁所有聚簇索引记录+间隙），尤其在 READ-COMMITTED 或更高隔离级别下更明显。不是“优化器自动避让”，而是根本没得选。
- 执行前务必确认
WHERE字段有有效索引，用EXPLAIN看type是否为range/ref，别信“小表无所谓” - 禁止在生产环境跑
UPDATE table SET col = ?;这种无条件语句，哪怕只有一行数据，也可能触发全表扫描+全表加锁 - 如果真要全量更新，先用
SELECT COUNT(*)确认行数，再拆成带主键范围的分批语句，而不是硬扛
分批更新时 LIMIT 子句不生效，还是锁住大量行
LIMIT 在 UPDATE 中只限制修改行数，但 InnoDB 仍需扫描并加锁所有满足 WHERE 条件的行——除非你用主键/索引字段做范围切割。
- 错误写法：
UPDATE t SET status=1 WHERE status=0 LIMIT 1000;→ 扫描全部status=0行，只改前 1000 行，其余全锁着 - 正确思路：按主键分段，例如
UPDATE t SET status=1 WHERE status=0 AND id BETWEEN 10000 AND 19999; - 每次更新后记录最大
id，下次从id > 19999开始查，避免漏数据或重复处理 - 注意：
BETWEEN包含边界，且要求id是单调递增的整型主键；如果是 UUID 或复合主键，得换用时间戳+自增辅助列
脚本执行中被 kill 或崩溃，导致更新不完整又难回滚
分批脚本不是“执行完就完事”，中间断掉后，既不能简单重跑（怕重复更新），也不能靠人工核对（线上不敢停）。
- 每批次更新前，先插入一条日志到专用表（如
update_progress），包含批次标识、起始id、状态running - 更新成功后，用事务把数据更新和日志状态更新一起提交，状态改为
done - 脚本启动时先查
update_progress，跳过所有done记录，只从最后一个running或pending处继续 - 别依赖脚本里的本地变量存进度，数据库才是唯一可信的状态源
为什么不用存储过程写分批逻辑？
看起来省事，但 MySQL 存储过程在长事务中容易卡死连接、阻塞复制线程，且调试困难，出错时堆栈信息极其有限。
- 存储过程里用
WHILE+UPDATE ... LIMIT，本质还是逐批扫表，锁问题没解决 - 无法方便地监控每批耗时、失败率、QPS 影响，运维层面不可见
- 一旦过程卡住，只能
KILL连接，但已执行的批次没日志，后续无法判断是否完成 - 推荐用 Python/Shell 写外部脚本：可设超时、捕获
Deadlock found错误重试、发告警、集成到 CI/CD 流水线
真正麻烦的从来不是“怎么分批”，而是“怎么确保每批都原子、可观测、可中断恢复”。索引没建好、日志没落库、脚本没超时控制——这三样占了线上事故的八成。
