INNER JOIN 是最常用的 JOIN 类型，因其天然适配主键-外键等值映射的业务逻辑，如 orders.user_id = users.id；数据库优化器对等值连接有深度支持，可自动选用哈希、归并或索引连接等高效算子；且 92/99 语法均能清晰表达，但需警惕字段无索引、类型不一致或 NULL 导致的关联失败。
INNER JOIN 是最常用的 JOIN 类型，不是因为它“语法最短”或“名字好听”，而是因为绝大多数业务查询天然依赖主键-外键匹配关系——这种关系恰好由等值连接直接建模。
等值连接对应真实业务逻辑
订单表 orders 和用户表 users 之间，靠 orders.user_id = users.id 关联；商品表 products 和分类表 categories 之间，靠 products.category_id = categories.id 关联。这些都不是模糊匹配、范围匹配或存在性判断，而是明确的“相等”关系。
- 几乎所有规范化数据库的外键约束都强制这种一对一/一对多的等值映射
- 应用层写查询时，第一反应就是“我要把 A 表里某个 ID 对应的 B 表信息捞出来”，这直接翻译成
ON a.x = b.y - 非等值连接（比如
a.price > b.min_price）需要额外业务语义支撑，出现频次低得多
数据库优化器对等值连接有深度支持
主流数据库（MySQL、PostgreSQL、Oracle、达梦）的查询优化器默认为 = 条件设计了多种高效物理算子：哈希连接（Hash Join）、归并连接（Merge Join）、索引连接（Index Nested Loop Join）。这些算子在数据量大、字段有索引时能显著提速。
-
ON子句中用=且两边字段都有索引 → 很可能触发 Index Nested Loop - 两表都按连接字段排序 → 可能选 Merge Join，避免构建哈希表的内存开销
- 小表 + 大表，无排序但连接字段高选择性 → Hash Join 常被自动选用
- 换成
>或BETWEEN，这些优化路径基本失效，退回到嵌套循环或全表扫描
92语法和99语法都能自然表达等值连接
虽然 SQL-92 标准推荐用 INNER JOIN ... ON，但很多老项目、脚本、报表工具仍混用 SQL-92（逗号语法 + WHERE）。而等值连接在这两种写法下都清晰、无歧义：
- 99语法：
SELECT * FROM orders JOIN users ON orders.user_id = users.id - 92语法：
SELECT * FROM orders, users WHERE orders.user_id = users.id - 两者语义一致，迁移成本低；但非等值条件在 92 语法里容易和过滤条件混淆，可读性下降
容易踩的坑：别把等值连接当成“自动去重”或“天然安全”
等值连接只是按条件拼行，它不保证结果唯一，也不校验数据一致性。实际写的时候常掉进这几个坑：
- 连接字段没索引 → 全表扫描，10万行 × 10万行 = 100亿次比较
- 外键未建索引或允许 NULL →
NULL = NULL不成立，导致关联失败（尤其 MySQL 中） - 连接字段类型不一致（如
INTvsVARCHAR）→ 隐式转换，索引失效，还可能因字符集导致匹配错误 - 误以为
JOIN默认是等值连接 → 实际上JOIN本身不带条件，必须显式写ON或USING，否则变成笛卡尔积
真正难的从来不是写出等值连接，而是确认那两个字段确实该相等、能相等、且在所有数据场景下都稳定相等。字段语义模糊、历史数据脏、迁移后类型变更——这些问题不会在 ON a.x = b.y 这一行报错，但会在结果里悄悄少几万条记录。
