left join出现重复行时，应通过子查询聚合、窗口函数（如row_number()）、标量子查询（mysql 5.7）或lateral join（postgresql）控制右表仅返回一条匹配记录，并确保相关字段有联合索引；同时须将右表过滤条件置于on而非where中以避免left失效。
LEFT JOIN后出现重复行，怎么只取每个左表记录对应的一条右表数据
LEFT JOIN本身不保证“一对一”，只要右表有多个匹配项，左表那行就会被复制多次。这不是bug，是SQL的标准行为。想精准匹配，得主动控制右表的参与行数。
常见错误现象：SELECT * FROM orders LEFT JOIN order_items ON orders.id = order_items.order_id 导致一个订单在结果里出现3次（对应3个商品），但你只想看“首件商品”或“最新商品”。
- 用子查询先聚合右表：比如对
order_items按order_id分组，用MIN(id)或MAX(created_at)拿到目标行的主键，再JOIN回来 - 用窗口函数（推荐）：在支持
ROW_NUMBER()的数据库（PostgreSQL、SQL Server、MySQL 8.0+）中，给每组右表记录编号，只取rn = 1 - 避免用
LIMIT 1或TOP 1直接套在JOIN里——语法不合法，且无法关联到左表条件
MySQL 5.7不支持窗口函数，怎么安全实现“取第一条”
MySQL 5.7没有 ROW_NUMBER()，也不能在JOIN中直接用相关子查询限制数量，硬写容易出错或性能崩坏。
可行方案是用“相关标量子查询” + (SELECT ... LIMIT 1)，但必须确保子查询能命中索引，否则全表扫描代价极高：
SELECT o.id, o.order_no, (SELECT item_name FROM order_items oi WHERE oi.order_id = o.id ORDER BY oi.created_at DESC LIMIT 1) AS latest_item_name FROM orders o;
- 关键：
order_items(order_id, created_at)必须有联合索引，否则ORDER BY ... LIMIT 1会慢到不可用 - 不能用
GROUP BY o.id配合ANY_VALUE()来“糊弄”去重——它不保证取的是最新/最准的那条，行为不可控 - 如果需要多列（比如同时取
item_name和quantity），标量子查询要拆成多个，或改用派生表 + 索引优化的JOIN
PostgreSQL里用LATERAL JOIN替代LEFT JOIN做可控关联
LATERAL 是比普通LEFT JOIN更灵活的机制，允许右表子查询引用左表字段，并天然支持 LIMIT，语义清晰且执行计划通常更优。
例如取每个订单的最新一条物流记录：
SELECT o.id, o.order_no, l.status, l.updated_at FROM orders o LEFT JOIN LATERAL ( SELECT status, updated_at FROM logistics l2 WHERE l2.order_id = o.id ORDER BY l2.updated_at DESC LIMIT 1 ) l ON true;
-
LATERAL子查询可安全使用ORDER BY + LIMIT，且每次只对当前o.id执行，不会扫全表 - 注意结尾的
ON true：因为LATERAL本身不带ON条件，LEFT语义靠这个显式维持 - 相比嵌套标量子查询，
LATERAL更易扩展（比如加WHERE过滤物流状态）、也更容易被优化器识别为索引驱动
为什么加了WHERE条件后LEFT JOIN变成INNER效果
这是最容易被忽略的陷阱：把本该写在ON里的右表过滤条件，错写在WHERE里，导致LEFT失效。
比如想查“所有订单 + 其最新物流状态（即使没物流记录也显示NULL）”，但写了：
SELECT o.id, l.status FROM orders o LEFT JOIN logistics l ON o.id = l.order_id WHERE l.status = 'shipped'; -- ❌ 错！这会过滤掉l.status为NULL的所有行
- 正确做法：把右表的过滤条件移到
ON子句里：LEFT JOIN logistics l ON o.id = l.order_id AND l.status = 'shipped' - 原理：LEFT JOIN先按ON条件生成中间结果，再应用WHERE；而WHERE是在JOIN之后执行的全局过滤
- 如果确实需要按右表字段筛选但又保留左表全集，只能用子查询或CTE先准备好“符合条件的右表视图”，再LEFT JOIN过去
实际业务中，“精准一对多匹配”的难点不在语法，而在明确“精准”的定义——是时间最新？金额最高？ID最小？还是业务规则指定的某条。选错排序依据或过滤位置，结果就完全失真。
