SELECT ... JOIN 卡住其他事务的根本原因是隔离级别下的锁机制：MySQL在REPEATABLE READ下加gap lock阻塞插入，PostgreSQL在READ COMMITTED下仅锁命中行但全表扫描会扩大锁范围。
为什么 SELECT ... JOIN 会卡住其他事务？
根本原因不是 JOIN 本身慢，而是数据库在执行时按隔离级别加了不同粒度的锁。比如在 REPEATABLE READ 下，MySQL 的 InnoDB 可能对扫描范围内的索引间隙加 gap lock，导致插入被阻塞；而 PostgreSQL 在 READ COMMITTED 下只锁命中的行，但 JOIN 多表时若没走索引，容易升级成全表扫描锁。
- 检查执行计划：用
EXPLAIN ANALYZE看是否出现Using temporary或Using filesort，这类操作常伴随隐式锁扩大 - JOIN 字段必须有索引，且类型严格一致——
user_id INT关联order.user_id BIGINT会导致索引失效，进而触发全表扫描锁 - 避免在事务里先
UPDATE再SELECT ... JOIN，InnoDB 会对已修改的行加next-key lock，连带锁住后续可能插入的位置
READ COMMITTED 能解决死锁但代价是什么？
它确实减少锁持有时间，语句执行完就释放非唯一索引上的锁（MySQL 8.0+），但代价是：幻读风险上升、一致性视图只在语句级生效，同一事务内两次 SELECT ... JOIN 可能返回不同结果。
- PostgreSQL 默认就是
READ COMMITTED，但它的 MVCC 实现不依赖 gap lock，所以高并发写入下比 MySQL 更稳 - MySQL 若切到
READ COMMITTED，需确认 binlog 格式为ROW，否则主从延迟或数据不一致 - 别指望它“自动”解决所有锁冲突——如果两个事务都按不同顺序访问相同三张表（A→B→C vs C→A→B），依然会死锁
怎么让 LEFT JOIN 不拖垮事务性能？
LEFT JOIN 的驱动表选择错误，会让本该小结果集的表变成被驱动方，触发 N×M 次锁等待。更隐蔽的问题是：NULL 值参与 JOIN 条件时，索引可能完全失效。
- 强制指定驱动表：MySQL 用
STRAIGHT_JOIN，PostgreSQL 用/*+ Leading(t1 t2) */提示（需开启pg_hint_plan） - 把过滤条件尽量下推到 JOIN 子句里，而不是写在
WHERE中——WHERE t2.status IS NOT NULL会让 LEFT JOIN 变成 INNER JOIN 效果，还可能让优化器误判 - 对可能为 NULL 的字段建函数索引：比如
CREATE INDEX idx_user_email_lower ON users (LOWER(email))，避免ON LOWER(t1.email) = LOWER(t2.email)失去索引
事务里嵌套 JOIN 查询 + FOR UPDATE 怎么不锁过头？
加锁范围由 WHERE 条件和 JOIN 路径共同决定，不是只锁最终结果行。比如 SELECT ... FROM a JOIN b ON a.id = b.a_id FOR UPDATE，InnoDB 会同时锁住 a 表匹配行和 b 表关联行，哪怕你只打算更新 a。
- 只锁定真正要改的表：用
SELECT ... FROM a JOIN b ... FOR UPDATE OF a（PostgreSQL 支持），MySQL 则只能拆成两步——先查 ID，再用WHERE id IN (...)单表加锁 - 避免在
FOR UPDATE语句里用子查询 JOIN，某些版本 MySQL 会锁住子查询扫描的所有中间结果 - 超时设置不能只靠
innodb_lock_wait_timeout，应用层必须设SET LOCK_TIMEOUT 5000（PostgreSQL）或捕获Lock wait timeout exceeded错误并重试
最麻烦的是多层级 JOIN 配合外键约束，InnoDB 会自动在父表上加共享锁——这个行为不会出现在执行计划里，也很难被监控工具捕获。
