INNER JOIN只返回两表联结字段值均存在的交集行；ON控制连接逻辑，WHERE控制连接后筛选；必须用表别名避免歧义；NULL值因=判断返回UNKNOWN而被自动排除。
INNER JOIN 语法结构和基本写法
INNER JOIN 只返回两张表中联结字段值都存在的行，不是“取并集”也不是“取全集”，而是严格匹配交集。写错 ON 条件或漏写条件，结果可能为空或远少于预期。
-
JOIN和INNER JOIN完全等价，可以互换，但显式写INNER JOIN更清晰 -
ON后必须是布尔表达式，常见错误是误用WHERE替代ON（尤其多表连接时逻辑会偏移） - 联结字段类型要兼容，比如
user_id是INT，另一张表对应字段不能是VARCHAR存数字字符串，否则隐式转换可能失效或性能暴跌 - 示例：
SELECT u.name, o.order_date<br>FROM users u<br>INNER JOIN orders o ON u.id = o.user_id
ON 和 WHERE 的区别到底在哪
这是最常被混淆的点：ON 控制“怎么连”，WHERE 控制“连完再筛”。对 INNER JOIN 来说，多数时候结果一样，但逻辑不同、可读性差、嵌套查询或外连接下会出错。
- 把过滤条件写在
ON中（如ON u.id = o.user_id AND o.status = 'paid'）→ 这些条件参与连接过程，影响哪些行能被关联上 - 把同样条件写在
WHERE中 → 先完成全部连接，再从结果里剔除不满足的行 - 当涉及多个 JOIN 时，
ON中的条件只作用于当前两表，而WHERE会作用于最终结果集，容易误删本该保留的中间行 - 性能上，数据库优化器通常能重写，但显式写在
ON更利于理解意图
别名（alias）为什么不能省，又该怎么起
没加表别名就直接用字段名，99% 会触发 Column 'xxx' in field list is ambiguous 错误。别名不是偷懒，是避免歧义的强制要求。
- 必须为每张参与 JOIN 的表指定别名（哪怕只用一次），例如
FROM users u、JOIN orders o - 所有字段引用都带别名前缀：
u.name、o.total，不写前缀在多表场景下直接报错 - 别名尽量简短但有意义，避免用
a/b这类无提示性命名；也别用 SQL 关键字如order或user（即使加反引号也不推荐） - 如果字段名在两张表中完全一致（如都叫
id），不加别名根本无法 SELECT，连SELECT *都可能因重复列名失败（取决于客户端驱动）
连接字段有 NULL 值时会发生什么
INNER JOIN 天然跳过任何一侧为 NULL 的记录——因为 = 判断在 SQL 中对 NULL 返回 UNKNOWN，不满足 TRUE，所以不会进入结果集。
- 如果某张表的关联字段大量为
NULL（比如orders.user_id为空表示匿名订单），这些记录会被直接丢弃，不是“没匹配上”，而是“根本不参与匹配” - 想保留这类记录？得换
LEFT JOIN，再配合WHERE o.user_id IS NULL等条件筛选 - 检查数据质量时，可用
SELECT COUNT(*) FROM orders WHERE user_id IS NULL先确认 NULL 比例，避免 JOIN 后数据量突降引发误判
ON 条件，最后补上别名和前缀——顺序错了，调试成本会翻倍。 
