大表update锁全表主因是未走索引导致全表扫描并加大量行锁；where条件无索引、区分度低、复合索引顺序错、隐式类型转换均会失效；分批更新须用主键范围而非limit offset。

大表 UPDATE 锁全表，根本不是语句“写错了”，而是 MySQL 在执行时被迫扫全表 + 持有大量行锁 + 事务不提交，最终等效于锁表。只要没走索引、单次改太多、或事务卡住，就大概率触发。

WHERE 没走索引：锁表的头号原因

哪怕你写了 WHERE status = 'pending'，只要 status 列没有索引，或区分度极低（比如 95% 都是 pending），优化器就会放弃走索引，直接全表扫描。InnoDB 会对每一条扫描到的行加 next-key lock——扫 1000 万行，就锁 1000 万行，其他事务一碰就等。

• 用 EXPLAIN FORMAT=TREE 看 type 字段：要是 ALL 或 index，基本就是全表/全索引扫描
• key 为空，或显示的不是你建的那个索引名，说明没命中
• 复合索引顺序必须匹配查询条件：比如 (deleted, create_time) 能用上 deleted = 0，但 (create_time, deleted) 就不一定
• 隐式类型转换会失效：user_id 是 BIGINT，却传字符串 '123'，索引直接跳过

MySQL 分批 UPDATE 必须用主键游标，不能靠 LIMIT OFFSET

UPDATE ... LIMIT 5000 看似能控制数量，但它不解决扫描问题：WHERE 条件仍可能全表扫，只是最后只改前 5000 行。真正安全的分片，得靠单调递增字段（如 id）做范围切分，每次只扫一小段。

• 正确写法：UPDATE orders SET status = 'shipped' WHERE id > 100000 AND id
• 下一批起点必须是上一批的 MAX(id)，不是靠 SELECT COUNT 算总页数
• 禁用 OFFSET：并发更新时数据变动会导致偏移漂移，漏更或重复
• 每批单独事务，执行完立刻 COMMIT，锁才真正释放

SQL Server 的 TOP 分批更简单，但必须配 ORDER BY 和事务控制

SQL Server 支持 UPDATE TOP(n)，语法更直白，但容易忽略两个关键点：一是没 ORDER BY 会导致同一批重复更新或漏更；二是没显式事务包裹，每条 TOP 都是独立事务，反而增加开销。

• 必须写成：BEGIN TRANSACTION; UPDATE TOP (1000) t SET flag = 1 FROM logs t WHERE t.flag = 0 ORDER BY id; COMMIT;
• 终止条件用 IF @@ROWCOUNT = 0 BREAK，别预估总行数
• 避免 WHERE id IN (SELECT ...)：子查询可能缓存在 tempdb，几十万 ID 就吃光内存，还扩大锁范围
• 锁升级阈值默认 5000 行，所以批次建议严格控制在 1000–5000

最容易被忽略的一点：分批脚本上线前，必须在从库或备份库完整跑一遍，确认最终更新总数和业务逻辑完全对得上——因为 WHERE 条件里混了状态字段（比如 status = 'pending'）时，中间若有新插入或并发修改，游标推进就可能错位。