INNER JOIN查不到数据主因是ON条件误用==或IS，正确必须用=；字段类型不一致会导致隐式转换和索引失效；LEFT JOIN误写为INNER JOIN会过滤孤立记录；多表JOIN需注意驱动表顺序、索引覆盖及EXPLAIN分析。
INNER JOIN 语法写错，查不到数据？先看 ON 条件是否用了 = 而不是 == 或 IS
MySQL 不支持 ==，也不接受 IS 作连接条件（那是 NULL 判断用的）。INNER JOIN 必须用 = 做等值匹配，否则会报错或返回空结果。
-
ON a.id = b.user_id✅ 正确 -
ON a.id == b.user_id❌ 报错：ERROR 1064 -
ON a.id IS b.user_id❌ 语法错误，IS只能跟NULL - 如果字段类型不一致（比如
INT连VARCHAR），MySQL 会隐式转换，但可能走不了索引——建议提前ALTER TABLE统一类型
LEFT JOIN 写成了 INNER JOIN，结果变少？确认业务逻辑是否真要「必须匹配」
INNER JOIN 天然过滤掉任一侧为 NULL 的行。如果你发现结果比预期少，大概率是某张表里存在孤立记录（比如订单表有 user_id=999，但用户表没这条数据）。
- 用
SELECT COUNT(*) FROM orders WHERE user_id NOT IN (SELECT id FROM users)快速验证是否存在孤儿外键 - 想保留主表所有行，就该换
LEFT JOIN；想只取交集，才用INNER JOIN - 别依赖
USING (col)简写，它要求两表字段名完全一致且类型兼容，容易在字段重命名后突然失效
多表 JOIN 性能崩了？检查驱动表顺序和索引覆盖
MySQL 从左到右执行 JOIN，左边的表是驱动表。如果第一张表太大、又没合适索引，后面每连一张表都要全表扫描一次。
- 把小表（如状态字典表）放前面，大表（如日志表）放后面
- 确保
ON条件里的字段都有索引，尤其是被驱动表的关联列（如b.user_id上要有索引） - 用
EXPLAIN SELECT ...看type是否为ref或eq_ref，避免出现ALL - 别在
ON里写函数，比如ON YEAR(a.create_time) = YEAR(b.date)，会导致索引失效
WHERE 和 ON 都能筛数据，到底该放哪？区分「连接逻辑」和「结果过滤」
ON 控制两张表怎么连，WHERE 是连完再筛。对 INNER JOIN 来说，放哪效果一样；但一旦换成 LEFT JOIN，位置不同结果天差地别——所以养成习惯：只在 ON 写关联条件，其余筛选一律丢 WHERE。
-
ON a.status = 'active' AND b.type = 'paid'❌ 错，这不是关联依据，是业务规则 -
ON a.user_id = b.id WHERE a.status = 'active'✅ 清晰分离职责 - 如果
WHERE里写了右表字段（如WHERE b.amount > 100），INNER JOIN下没问题，但会意外把本该保留的左表记录也干掉——这点很容易被忽略
ON，或者没意识到字段类型隐式转换带来的性能断崖。连三张表以上时，务必用 EXPLAIN 看执行计划，而不是靠猜。 
