inner join 必须显式写 on 条件，否则等同于 cross join；on 条件需确保字段类型与字符集排序规则一致，过滤条件应优先置于 on 而非 where 以提升性能，多表连接须按依赖链顺序书写。
INNER JOIN 必须显式写 ON 条件，不能省略
不写 ON 就执行 INNER JOIN，结果等同于 CROSS JOIN——也就是笛卡尔积，数据量是两表行数相乘，轻则查不出结果，重则拖垮数据库。很多新手在调试时发现查询极慢或返回百万行，第一反应是“索引没建好”，其实只是漏了 ON。
-
INNER JOIN关键字本身不带任何逻辑，它只表示“连接”，真正决定哪些行能匹配的是ON后面的表达式 - 别用旧式逗号语法：
SELECT * FROM users, orders WHERE users.id = orders.user_id，可读性差、易漏条件、JOIN 顺序模糊 - 必须确保
ON中两边字段类型一致：比如users.id是INT，orders.user_id就不能是VARCHAR；否则 MySQL 可能放弃索引，转为全表扫描 - 如果外键字段允许
NULL，INNER JOIN会自动跳过这些行——这不是 bug，是设计行为，但容易让人误以为“数据丢了”
WHERE 和 ON 的位置影响执行计划和结果逻辑
把过滤条件放在 WHERE 还是 ON，表面看结果一样，实际执行路径可能完全不同，尤其涉及索引时。
- 状态类条件（如
orders.status != 'cancelled'）如果写在ON子句里，MySQL 更可能下推到 join 阶段，利用status上的索引提前剪枝 - 但如果写在
WHERE，就得先完成整个users INNER JOIN orders，再对结果集做二次过滤——中间结果更大，内存/IO 开销更高 - 更隐蔽的问题：当连接多于两张表时，
WHERE条件可能意外过滤掉本该由后续 JOIN 补上的行。例如WHERE o.created_at > '2024-01-01'放在最外层，会把没订单的用户彻底排除，而你本意只是“查最近下单的用户及其订单详情” - 验证方法：先跑不带
WHERE的INNER JOIN，用EXPLAIN看 rows 和 key 列；再加条件对比，观察是否出现Using where或Using temporary
三张及以上表 JOIN 必须按依赖链顺序书写
SQL 的 JOIN 是左关联：每次只把前一个结果集和新表连接，不是一次性把所有表笛卡尔积后再筛选。跳过中间表直接连首尾，要么报错，要么返回空。
- 正确路径：用户 → 订单 → 订单明细，对应
users u INNER JOIN orders o ON u.id = o.user_id INNER JOIN order_items oi ON o.id = oi.order_id - 错误写法：
users u INNER JOIN order_items oi ON u.id = oi.user_id—— 如果order_items表没有user_id字段，直接语法报错；如果有但没索引，查询会全表扫order_items去匹配每个用户，性能灾难 - 别指望优化器自动“补路”：即使
orders和order_items有外键，优化器也不会帮你隐式插入中间表 - 表别名必须紧跟
FROM和每个JOIN后，否则SELECT中字段引用会歧义，比如id到底是users.id还是orders.id
字符集和排序规则不一致会导致 ON 匹配失败
字段类型相同还不够，utf8mb4_0900_as_cs 和 utf8mb4_general_ci 混用时，等值判断可能返回 false，即使值看起来完全一样。
- 典型现象：两个字段都是
VARCHAR(32)，值都是'admin'，但INNER JOIN结果为空 - 检查方式：
SHOW FULL COLUMNS FROM table_name，重点看Collation列 - 修复优先级：先统一 collation（如都设为
utf8mb4_0900_as_cs），其次才是改字段类型或加COLLATE强制转换 - 临时绕过（不推荐）：
ON u.username = o.username COLLATE utf8mb4_0900_as_cs，但会影响索引使用，且难维护
实际写的时候，最容易被忽略的是字段类型和 collation 的隐式不兼容，以及把业务语义上属于“连接约束”的条件（比如订单状态、时间范围）错误地扔进 WHERE。这两点不会立刻报错，但会在数据量上来后突然变慢，或者在某些边缘 case 下漏数据。
