mysql update大表时看似锁全表，实为行锁升级+mvcc版本链拉长导致阻塞；分批更新须基于主键范围切分、控单事务≤1000行、加短延时，禁用offset；无索引时优先加索引或改用主键子查询。
UPDATE 大表时为什么锁全表
MySQL 的 UPDATE 在未命中索引或扫描行数过多时，InnoDB 会升级锁粒度——从行锁退化为间隙锁甚至表级意向锁，配合事务隔离级别（尤其是 REPEATABLE READ），实际效果就是“像锁了整张表”。你看到的“卡住其他查询”，往往不是真锁表，而是大量行锁堆积 + MVCC 版本链拉长，导致后续语句等锁、等回滚、等 purge 线程清理旧版本。
常见错误现象：SHOW PROCESSLIST 里一堆 Updating 状态；SELECT 查询明显变慢甚至超时；INFORMATION_SCHEMA.INNODB_TRX 显示事务长时间运行且 TRX_ROWS_LOCKED 高达百万级。
分批 UPDATE 的核心控制点
分批不是简单加个 LIMIT 就完事。关键在三件事：用主键/唯一索引驱动分页、控制每批事务大小、避免 OFFSET 滚动扫描。
- 必须基于主键范围切分，例如：
WHERE id BETWEEN ? AND ?，而不是LIMIT 1000 OFFSET 10000（后者越往后越慢，且可能漏数据） - 每批提交前确认影响行数，用
ROW_COUNT()判断是否还有数据可处理 - 单事务控制在 1000 行以内（具体看单行大小和 binlog 格式，
STATEMENT模式下大事务更危险） - 批次间加短延时（如
SLEEP(0.1)），缓解主从复制压力和锁竞争
示例逻辑（伪代码）：
SET @start_id = 0; WHILE @start_id @start_id AND id <h3>WHERE 条件没走索引怎么办 </h3><p>这是最常踩的坑：以为加了 <code>LIMIT</code> 就安全，结果执行计划显示 <code>type: ALL</code>，全表扫描+全表加锁。分批的前提是每次都能快速定位到下一批起点。</p> <p>使用场景：你要改的是 <code>WHERE create_time > '2023-01-01'</code> 这类时间范围字段，但该字段没索引。</p>
- 先加索引：
ALTER TABLE t ADD INDEX idx_create_time (create_time)（注意评估加索引期间的锁表风险） - 如果不能加索引，改用主键关联子查询：
UPDATE t SET status = 1 WHERE id IN (SELECT id FROM (SELECT id FROM t WHERE create_time > '2023-01-01' LIMIT 1000) AS tmp)（MySQL 8.0+ 支持，5.7 需拆成两步） - 禁止写
UPDATE ... JOIN ... WHERE ... LIMIT，MySQL 不允许对多表更新加LIMIT
binlog 和主从延迟怎么兼顾
分批提交能降低单事务体积，但高频小事务会显著增加 binlog I/O 和主从 relay log 应用压力，尤其在 STATEMENT 格式下，每条 UPDATE 都要重放。
- 优先用
ROW格式 binlog，避免语句重放歧义 - 调大从库
slave_parallel_workers（需开启slave_parallel_type = LOGICAL_CLOCK） - 避免在业务高峰期执行；观察
Seconds_Behind_Master，若持续增长，主动暂停几秒再继续 - 不要依赖
AUTO_COMMIT=0手动控制事务——容易忘COMMIT，反而拖更久
真正麻烦的是那些没法加索引、又必须改历史冷数据的场景：这时候分批只是把“一次锁死”变成“反复锁一小片”，锁等待仍存在，得结合业务停写窗口或应用层灰度控制。
