最拖后腿的是 EXPLAIN ANALYZE 中 Actual Total Time 最高（PG）或 Query_time 与 Rows_examined 比例严重失衡（MySQL）的节点，如 Nested Loop 配合大表扫描、Seq Scan 无索引字段、type=ALL 或 Using temporary/filesort；需检查 JOIN 字段类型一致、索引存在且顺序匹配、避免条件中用函数。
怎么看执行计划里哪一步最拖后腿
直接看 EXPLAIN ANALYZE 输出中最耗时的节点，尤其是 Nested Loop 配合大表扫描、或 Seq Scan 在没索引的字段上反复出现——这些不是“可能慢”，是“一定慢”。PostgreSQL 里注意 Actual Total Time，MySQL 看 Query_time 和 Rows_examined 的比例：如果查 10 行却扫了 10 万行，JOIN 条件大概率没走索引。
常见错误现象：EXPLAIN 显示 Using temporary; Using filesort 出现在 JOIN 后的 ORDER BY 或 GROUP BY；或者 type=ALL（全表扫描）出现在被驱动表上。
- 先确认 JOIN 字段类型是否严格一致（比如
user_id INT和log.user_id BIGINT会导致索引失效） - 检查被驱动表的 ON 条件字段是否有索引，且顺序匹配（
ON a.id = b.a_id→b.a_id要有单列索引或作为联合索引最左前缀） - 避免在 JOIN 条件里用函数，比如
ON LOWER(a.email) = LOWER(b.email)，索引基本作废
为什么加了索引还是走不了索引
索引没被选中，不一定是建错了，更可能是优化器觉得“走索引不如全扫快”。典型场景是表小（
使用场景：你刚给 orders.user_id 加了索引，但 SELECT * FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' 还是慢。
- 运行
ANALYZE orders（PostgreSQL）或ANALYZE TABLE orders（MySQL），强制更新统计信息 - 检查
WHERE条件字段（如u.status）是否也参与了索引——单列user_id索引对u.status = 'active'没用 - 用
pg_stat_all_indexes（PG）或SHOW INDEX FROM orders（MySQL）确认索引状态，留意indexdef是否含表达式或部分索引限制
锁等待怎么一眼识别是 JOIN 引起的
当查询卡住不动，且 pg_stat_activity 里看到 wait_event_type = 'Lock'、wait_event = 'transactionid' 或 wait_event = 'relation'，同时 state = 'active' 但 backend_start 和 state_change 时间差很大，基本就是锁住了。
性能影响：一个长事务在 UPDATE users SET last_login = now() WHERE id = 123，另一个 JOIN 查询 SELECT u.*, o.* FROM users u JOIN orders o ON u.id = o.user_id 就可能被阻塞——因为 users 行锁升级为表级锁，或 orders 上的共享锁与更新锁冲突。
- 查锁源头：
SELECT blocked_locks.pid AS blocked_pid, blocking_locks.pid AS blocking_pid FROM pg_catalog.pg_locks blocked_locks JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid AND blocking_locks.pid != blocked_locks.pid WHERE NOT blocked_locks.granted; - 避免方案：JOIN 查询加
FOR SHARE或FOR UPDATE OF要谨慎；高并发写场景下，把 JOIN 拆成两步（先查主键，再按 ID 批量查关联表）反而更稳
LEFT JOIN 变 INNER JOIN 是谁动的手
不是语法写错了，是优化器干的。当你在 LEFT JOIN 后加了 WHERE b.status IS NOT NULL，PostgreSQL/MySQL 都会悄悄把 LEFT JOIN 改成 INNER JOIN 处理——因为 WHERE 条件过滤掉了 NULL 行，语义等价。
容易踩的坑：你以为能查出所有用户+他们的订单（没有订单就显示 NULL），结果发现没订单的用户根本不出现在结果里。
- 检查执行计划里是否出现
Join Filter: (b.status IS NOT NULL)且Rows Removed by Join Filter数值很大 - 想保留左表全部记录，把
WHERE条件挪到ON子句里：LEFT JOIN orders b ON a.id = b.user_id AND b.status IS NOT NULL - 注意 NULL 安全比较：用
IS NOT DISTINCT FROM替代=可避免隐式转换导致的 JOIN 退化
复杂点在于，有些慢查询表面是数据量大，实际是锁、统计偏差、或优化器误判三者叠加。别急着加索引，先盯住 EXPLAIN ANALYZE 里那个最刺眼的 Actual Time 数字，它不会说谎。
