INNER JOIN 是SQL内连接操作，返回两表中联结字段值均存在的记录（即交集），基本语法为 SELECT 列名 FROM 表1 INNER JOIN 表2 ON 表1.字段 = 表2.字段，必须显式指定 ON 子句且推荐使用表别名。
INNER JOIN 语法结构和基本写法
INNER JOIN 只返回左右两张表中联结字段值都存在的记录，本质是取交集。它不关心字段名是否相同，只看 ON 后的条件是否为真。
- 必须显式写出
ON子句，不能省略（有些方言允许用USING，但可读性差且限制多） - 表别名强烈建议加上，否则字段冲突时会报错：
Column 'id' in field list is ambiguous -
JOIN和INNER JOIN完全等价，后者更明确，推荐始终写全
SELECT u.name, o.order_date FROM users u INNER JOIN orders o ON u.id = o.user_id;
ON 和 WHERE 的区别必须分清
很多人把过滤条件随手塞进 WHERE，结果发现数据变少、甚至变成外连接效果——这是因为 ON 在连接阶段生效，WHERE 是连接完成后再过滤。
-
ON中的条件决定哪些行能“配对成功” -
WHERE中的条件是对已配对结果再筛，可能把本该保留的匹配行干掉
比如想查“上海用户下的有效订单”，错误写法：
SELECT * FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE u.city = 'Shanghai' AND o.status != 'cancelled';
这没问题；但如果写成：
SELECT * FROM users u INNER JOIN orders o ON u.id = o.user_id AND o.status != 'cancelled' WHERE u.city = 'Shanghai';
逻辑一致，但执行计划可能不同——尤其当 orders.status 有索引时，ON 条件更可能触发索引下推。
多表 INNER JOIN 容易漏掉中间依赖
三张表以上连查时，常见错误是跳过中间关联，直接让首尾两表“硬连”。
- 每次
JOIN都只作用于前一个结果集和新表，不是全局笛卡尔积后筛选 - 如果
table_a和table_c没有直接外键，却试图ON a.id = c.a_id，而c.a_id实际为空或未建索引，查询会极慢甚至超时
正确顺序示例（用户 → 订单 → 订单商品）：
SELECT u.name, o.order_no, oi.product_name FROM users u INNER JOIN orders o ON u.id = o.user_id INNER JOIN order_items oi ON o.id = oi.order_id;
如果漏掉 orders 这一层，直接 users 连 order_items，SQL 会报错或返回空——因为没有路径可循。
性能陷阱：没加索引 or 连接字段类型不一致
INNER JOIN 性能差，90% 出在连接字段没走索引，或者隐式类型转换导致索引失效。
- 确保
ON两侧字段类型完全一致（比如都是INT，或都是VARCHAR(32)），否则 MySQL/PostgreSQL 可能放弃使用索引 - 字符串字段注意排序规则（collation），
utf8mb4_0900_as_cs和utf8mb4_unicode_ci混用会导致无法索引匹配 - 复合索引要符合最左前缀原则：若
ON a.x = b.x AND a.y = b.y，则b(x,y)索引有效，b(y,x)无效
检查执行计划时重点关注 type 是否为 ref 或 eq_ref，如果是 ALL 或 index，基本说明连接没走索引。
实际写的时候，最容易被忽略的是连接字段的 NULL 值处理——INNER JOIN 自动跳过任一侧为 NULL 的行，但如果你的外键字段允许 NULL，又没在业务层约束，那这些记录就永远进不了结果集，还查不出原因。
