千万级表JOIN易锁表因UPDATE/DELETE带JOIN时隐式加行锁或间隙锁，若无索引或全表扫描则锁大量无关行，高并发下易死锁或超时。
千万级表JOIN时为什么容易锁表
MySQL执行 JOIN 本身不直接加表级锁，但实际阻塞常来自隐含的锁行为：当 UPDATE 或 DELETE 带 JOIN 时，优化器可能对驱动表或被驱动表的扫描范围加行锁（甚至间隙锁），若没走索引、或扫描全表，就会锁住大量无关行；高并发下多个事务交叉锁定不同行，极易触发死锁或锁等待超时。
常见错误现象包括：
-
SHOW PROCESSLIST中看到大量Waiting for table metadata lock或Updating状态长时间挂起 - 应用报错
Lock wait timeout exceeded; try restarting transaction -
SELECT ... FOR UPDATE或带JOIN的更新语句在低QPS下也明显变慢
确保驱动表小 + 连接列有高效索引
这是最直接影响锁范围和执行路径的两点。MySQL默认使用嵌套循环连接（NLJ），驱动表越小、被驱动表连接列索引越精准，扫描与加锁的行数就越少。
- 驱动表应优先选过滤后结果集小的那张表（比如
users表 10 万行，orders表 2000 万行，且你要更新「2025 年新注册用户对应的订单」，那就让users当驱动表） - 连接列必须有索引，且类型严格匹配（避免隐式转换）：
orders.user_id是INT，就别用WHERE u.id = '123'字符串比较 - 复合索引要覆盖查询条件+连接列，例如：
CREATE INDEX idx_user_regdate_type ON users(reg_date, user_type)，配合WHERE reg_date > '2025-01-01' AND user_type = 1可快速定位驱动表子集
用 WHERE 提前过滤，别依赖 JOIN 后再筛
很多开发者写成这样：
UPDATE orders o JOIN users u ON o.user_id = u.id SET o.status = 'processed' WHERE u.reg_date > '2025-01-01';
问题在于：MySQL 先完成 JOIN 扫描（可能全表扫 orders），再做 WHERE 过滤 —— 锁的是整个中间结果集里的所有匹配行。
正确做法是把过滤条件“下推”到驱动表：
UPDATE orders o JOIN ( SELECT id FROM users WHERE reg_date > '2025-01-01' ) u ON o.user_id = u.id SET o.status = 'processed';
这样驱动表子查询先走索引快速收敛，JOIN 仅触达目标用户关联的订单行，锁范围大幅缩小。
批量更新 + 限流，避开长事务
单条 UPDATE ... JOIN 更新百万行，事务日志暴涨、锁持有时间过长，极易阻塞其他业务。
- 改用分批：每次最多更新 5000 行，用主键 or 时间字段做游标
- 加
ORDER BY+LIMIT显式控制范围，避免优化器误选执行计划 - 每批之间加短延迟（如
SLEEP(0.1)），降低系统负载峰
示例片段：
UPDATE orders o JOIN users u ON o.user_id = u.id SET o.status = 'processed' WHERE u.reg_date BETWEEN '2025-01-01' AND '2025-01-31' AND o.id > 1000000 ORDER BY o.id LIMIT 5000;
注意：ORDER BY 字段必须有索引，否则 LIMIT 无法跳过已处理数据，反而导致重复或遗漏。
锁表问题真正难缠的地方不在语法，而在执行路径是否可控 —— 一个没走索引的 JOIN 条件，会让本该锁几百行的操作变成锁几十万行；而一个没加 ORDER BY 的分批更新，可能让重试逻辑彻底失效。
