主键关联不等于自动快，关键在驱动表小、右表索引有效、无隐式转换或逻辑误写；需通过explain验证type为eq_ref/ref、key有值、rows极小，三者缺一不可。

LEFT JOIN 关联两个主键时性能未必最优，但确实是最容易达成高性能的场景之一——前提是驱动表小、索引有效、且没有隐式转换或逻辑误写。

为什么主键关联不等于自动快

主键自带唯一性 + 非空 + 索引（InnoDB 中主键即聚簇索引），所以 c.id = cb.c_id 这类关联能走索引查找，避免右表全表扫描。但这只是必要条件，不是充分条件：

• 若左表 customer 有 2000 万行，没加 WHERE 过滤，MySQL 仍会逐行去右表用主键索引查一次——2000 万次索引查找，I/O 和 CPU 开销依然可观
• 若右表 customer_balances.c_id 是外键但没建索引（仅靠主键 id 无用），cb.c_id 字段就会触发全表扫描
• 若字段类型不一致（如左表 id 是 BIGINT，右表 c_id 是 VARCHAR），隐式转换会让右表索引失效

LEFT JOIN 主键关联的三个关键性能杠杆

真正起作用的是这三点组合，缺一不可：

• EXPLAIN 显示 type 为 eq_ref 或 ref：说明右表用了主键或二级索引快速定位，不是 ALL
• 左表被 WHERE 条件提前过滤：比如 WHERE c.name = 'xxx' 能把左表从 2000 万行压到 1 行，后续只做 1 次右表索引查找
• 右表关联字段单独建了索引：即使 c_id 不是主键，也必须有 INDEX(c_id)；复合索引如 INDEX(c_id, available_balance) 还能覆盖查询字段，避免回表

常见误操作：明明关联主键，却慢得离谱

这些写法会让主键优势完全失效：

• 在 WHERE 里对右表字段过滤：WHERE c.name = 'xxx' AND cb.available_balance > 100 —— 这会把 LEFT JOIN 实际退化成 INNER JOIN，且让优化器不敢下推过滤条件到右表
• 把大表放左边当驱动表：比如 LEFT JOIN customer_balances cb ON cb.c_id = c.id，而 customer_balances 有 1800 万行，customer 只有 2 万行，此时应交换表顺序或改用子查询
• 用函数包裹关联字段：ON c.id = CAST(cb.c_id AS SIGNED) 或 ON c.id = cb.c_id + 0，导致右表索引无法使用

验证是否真走主键索引的实操步骤

别猜，用 EXPLAIN FORMAT=TREE（MySQL 8.0+）看真实执行计划：

• 确认右表访问类型是 eq_ref（主键等值查）或 ref（二级索引查），不是 ALL 或 index
• 检查 key 列显示实际使用的索引名，比如 PRIMARY 或 idx_c_id
• 观察 rows 预估扫描行数：如果是 1 或个位数，说明索引生效；若和右表总行数接近，基本就是全扫了
• 留意 Extra 是否含 Using join buffer (hash) 或 Using temporary —— 这些是性能红灯

主键关联只是给了你“能快”的基础，真正的性能取决于你怎么用它：驱动表够不够小、右表索引建没建对、WHERE 条件放没放错位置。最容易被忽略的是——你以为在用主键索引，其实因为一个隐式转换或一个错误的 WHERE 子句，早就退化成全表扫描了。