JOIN 本身不锁表，而是因关联字段无索引或LEFT JOIN+WHERE误推导致全表扫描，触发间隙锁/临键锁；EXPLAIN FORMAT=JSON中key为null或rows_examined_per_scan过大是关键信号。
为什么 JOIN 会突然锁住整张表？
不是 JOIN 本身锁表，而是 MySQL 在执行过程中对涉及的行（甚至页、索引范围）加了过重的锁——尤其是当关联字段没索引、或用了 LEFT JOIN 配合 WHERE 条件误推到右表时，优化器可能放弃使用索引，触发全表扫描+间隙锁（Gap Lock）或临键锁（Next-Key Lock）。
- 常见错误现象：
SHOW ENGINE INNODB STATUS里看到大量LOCK WAIT，trx_state = LOCK WAIT，且等待锁类型是RECORD LOCKS或INSERT INTENTION，但被锁的行远超实际要查的几条 - 典型场景：订单表
orders和用户表users关联，orders.user_id没索引，又在WHERE users.status = 'active'上过滤 - 关键原因：MySQL 的可重复读（RR）隔离级别下，
JOIN中未命中的索引路径，会让优化器对左表扫描范围扩大，连带右表也被迫锁定更大范围
EXPLAIN 看不出锁问题？得加 FORMAT=JSON
EXPLAIN 默认只告诉你“走不走索引”，但锁行为藏在执行计划的访问路径细节里。必须用 EXPLAIN FORMAT=JSON 查看 used_columns、key_length 和 rows_examined_per_scan，才能判断是否发生隐式全表扫。
- 重点关注
"key": null或"key_length": 0—— 表示该表扫描没走索引，极大概率触发范围锁升级 - 如果
"rows_examined_per_scan"是几十万，而你只想要 10 条结果，说明锁粒度已经失控 - 别信
type: ref就安全：它只表示用了非唯一索引，但如果索引选择性差（比如status字段只有 2–3 个值），照样锁一大片
把 JOIN 拆成两步查，有时比硬调更稳
不是所有 JOIN 都值得保留。当右表参与过滤、且数据量小（IN 拉取，反而能避开锁竞争。
- 适用条件：右表查询条件明确、结果集可控（建议
SELECT id FROM users WHERE status = 'active' LIMIT 1000） - 注意
IN参数上限：MySQL 默认max_allowed_packet限制参数长度，超 1000 个 ID 建议分批或改用临时表 - 避免
IN (SELECT ...)：这种写法在旧版本 MySQL 里会退化为 N+1，且可能锁住子查询整个结果集 - 示例替换：
SELECT o.*, u.name FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'
→ 改为先SELECT user_id FROM orders WHERE ...，再SELECT * FROM users WHERE id IN (...)
READ COMMITTED 能降锁等级，但别乱切隔离级别
RR 级别下的间隙锁是过度锁主因；RC 级别下只锁命中行，不锁间隙，能显著减少锁冲突。但它不是银弹，得看业务能否接受不可重复读。
- 适合场景：报表类查询、后台导出、审计日志等不要求事务内多次读一致的地方
- 不适用场景：资金类操作、库存扣减、任何依赖“两次读相同”的逻辑
- 性能影响：RC 下 MVCC 版本链更短，一致性读开销略低，但写冲突检测变弱，可能增加
Deadlock found概率 - 设置方式：单语句级即可，不用改全局配置：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;+ 后续BEGIN
锁最狠的地方往往不在 SQL 写法，而在你以为“只是读”的地方——比如一个没加索引的 JOIN 条件，配合 RR 隔离级别，能让一行更新卡住几百个并发查询。盯紧 EXPLAIN FORMAT=JSON 里的 key_length 和 rows_examined_per_scan，比调优其他任何地方都管用。
