LEFT JOIN保留左表全部数据、RIGHT JOIN保留右表全部数据、INNER JOIN仅返回匹配行；根本区别在于基准表的数据完整性要求。
直接说结论：LEFT JOIN 保留左表全部数据，RIGHT JOIN 保留右表全部数据，INNER JOIN 只要匹配上的行——三者根本区别不在语法，而在「哪张表的数据必须全出来」。
LEFT JOIN 的行为和典型误用
LEFT JOIN 的核心是「左表不动，右表拼上去」。只要左表某行存在，不管右表有没有对应记录，这行都会出现在结果里；右表没匹配时，对应字段全是 NULL。
常见错误现象：
- 写成
SELECT * FROM orders LEFT JOIN customers ON orders.customer_id = customers.id，本意想查「所有客户及其订单」，结果却以orders为左表，实际查出的是「所有订单 + 可能缺失的客户信息」 - WHERE 条件误写在右表字段上（比如
WHERE customers.age > 30），会把本该保留的左表空匹配行过滤掉，等效于 INNER JOIN
正确做法：
- 明确主表是谁：要「列出所有客户」，就让
customers做左表 - 右表过滤条件必须写在
ON子句里（如ON customers.id = orders.customer_id AND orders.amount > 100），而不是WHERE
INNER JOIN 为什么常被默认使用
INNER JOIN（或简写为 JOIN）不保留任何一方的「残缺数据」，只输出两表都存在的关联记录。它性能通常最好，因为优化器容易利用索引跳过不匹配行。
但要注意：
- 如果连接字段没建索引，
INNER JOIN可能比LEFT JOIN更慢——因为前者需要双向匹配验证，后者只需扫左表再查右表 -
ON条件漏写或写错（比如写成ON a.id = b.user_id却忘了b.user_id是外键），会导致意外的空结果或笛卡尔积 - 别把
INNER JOIN当成「安全默认」：业务上需要展示无订单客户时，用它就会丢数据
RIGHT JOIN 几乎没必要单独用
RIGHT JOIN 逻辑上完全等价于调换左右表位置的 LEFT JOIN。比如：
SELECT * FROM customers RIGHT JOIN orders ON customers.id = orders.customer_id;
和下面这句语义一致：
SELECT * FROM orders LEFT JOIN customers ON orders.customer_id = customers.id;
所以实际项目中：
- 绝大多数团队禁用
RIGHT JOIN，统一用LEFT JOIN并靠调整表顺序表达意图 - 如果代码里突然出现
RIGHT JOIN，第一反应应该是「这里表顺序是不是写反了？」 - 某些旧迁移脚本或 ORM 自动生成 SQL 可能残留
RIGHT JOIN，但手动写新查询时应主动规避
ON 和 WHERE 的分界线最容易被忽略
这是 JOIN 类型行为差异的关键开关，不是语法细节，而是逻辑分水岭。
ON 决定「哪些行能连上」，WHERE 决定「连完之后还留哪些」。
- 对
LEFT JOIN：写在ON里的右表条件（如orders.status = 'paid'）只影响连接过程，左表行仍保留；写在WHERE里就会筛掉右表为NULL的那些左表行 - 对
INNER JOIN：两者效果通常一样，但语义不同——ON是连接逻辑，WHERE是结果过滤 - 一旦混用，特别是多表 JOIN 时，
WHERE放错位置可能让整个外连接退化成内连接
