join结果为空需先确认关联字段值是否真正匹配，检查数据类型、空格、不可见字符，确保类型一致并显式转换；inner join只返回匹配行，left join保留左表全部行；where条件位置影响left join结果；多表join需索引和合理顺序；on比using更灵活。
JOIN 查询结果为空？先确认关联字段值是否真正匹配
MySQL 的 JOIN 不会自动忽略大小写、空格或隐式类型转换带来的不匹配。比如 user_id 在一张表里是 INT，另一张是 VARCHAR，即使看起来数值相同（如 '123' 和 123），MySQL 可能因隐式转换失败导致关联失败。
- 用
SELECT分别查两张表的关联字段，检查数据类型、是否含空格（TRIM()）、是否含不可见字符（HEX()） - 确保 JOIN 条件两边字段类型一致，必要时显式转换：
ON CAST(t1.id AS CHAR) = t2.user_id -
LEFT JOIN时，右表字段为NULL不代表没数据，可能只是没匹配上——先查右表是否有对应记录
INNER JOIN 和 LEFT JOIN 的行为差异直接影响业务逻辑
很多人以为 LEFT JOIN “更安全”，但实际它会保留左表所有行，哪怕右表没匹配项，这可能导致统计结果虚高（比如统计用户订单数时，未下单用户也计入，计数为 0 但行数不变）。
-
INNER JOIN：只返回两表都能匹配上的行；适合“必须有关联”的场景，如查订单及其用户信息 -
LEFT JOIN：左表全量保留，右表无匹配则补NULL；适合“主表为主、补充信息”的场景，如列出所有用户及其最近一笔订单 - WHERE 条件写在
ON还是WHERE子句里，对LEFT JOIN结果影响极大——WHERE t2.status = 'paid'会过滤掉右表为NULL的行，等效于INNER JOIN
多表 JOIN 性能骤降？优先检查索引和连接顺序
三张及以上表 JOIN 时，执行计划容易失控。MySQL 优化器不一定按你写的顺序执行，但缺少索引时，它只能暴力嵌套循环，数据量稍大就卡住。
- 每张被 JOIN 的表，关联字段必须有索引（单列索引或联合索引的最左前缀）
- 用
EXPLAIN看type是否为ref或eq_ref；若出现ALL，说明某张表正在全表扫描 - 把结果集最小的表尽量放前面（例如先
JOIN一个带WHERE过滤的子查询），但最终仍以EXPLAIN实际输出为准 - 避免在
ON条件中使用函数，如ON YEAR(t1.created) = t2.year会导致索引失效
ON 和 USING 的区别不只是写法简洁问题
USING 看起来省事，但它要求两个表中字段名完全一致且类型兼容，而且一旦用了 USING，SELECT 中引用该字段就不能加表别名（否则报错），这点常被忽略。
-
ON t1.user_id = t2.id：字段名可不同，支持复杂表达式 -
USING (user_id)：要求两表都有名为user_id的列，且 SELECT 中直接写user_id，不能写t1.user_id -
USING生成的结果集中，该字段只出现一次；而ON会保留两列，需用别名避免歧义 - 如果后续要扩展 JOIN 第三方表，且其关联字段名不同，
ON更灵活、不易出错
