应使用子查询+ROW_NUMBER()预聚合右表或SQL Server专属OUTER APPLY。前者通过PARTITION BY分组、ORDER BY排序、rn=1筛选，后者用TOP 1子查询关联左表每行，二者均确保整行选取且不退化为INNER JOIN。

LEFT JOIN 时只取右表一条匹配记录，怎么写？

直接在 LEFT JOIN 的 ON 子句里加 TOP 1 是语法错误——SQL Server 不允许在 JOIN 条件中用 TOP，MySQL/PostgreSQL 更不支持。真正可行的路径是：把右表“先筛出每组一条”的逻辑提前做掉，再参与连接。

用子查询 + ROW_NUMBER() 预聚合右表

这是最通用、可读性好、且能精确控制“取哪一条”的方式。核心是给右表按分组字段排序编号，再外层过滤 rn = 1。

假设左表是 orders，右表是 order_logs，想对每个订单只连最新一条日志：

SELECT o.*, l.log_time, l.status
FROM orders o
LEFT JOIN (
    SELECT *,
           ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY log_time DESC) AS rn
    FROM order_logs
) l ON o.order_id = l.order_id AND l.rn = 1

• PARTITION BY order_id 确保每组订单独立编号
• ORDER BY log_time DESC 决定“最新”定义；若要最早，改 ASC
• AND l.rn = 1 必须写在 ON 里，不能放 WHERE，否则会退化为 INNER JOIN
• SQL Server、PostgreSQL、Oracle、MySQL 8.0+ 都支持 ROW_NUMBER()

用 APPLY 替代 LEFT JOIN（SQL Server 专属）

如果只跑 SQL Server，OUTER APPLY 是更自然的写法，语义上就是“对左表每行，执行一次右表子查询并取结果集第一行”。

SELECT o.*, l.log_time, l.status
FROM orders o
OUTER APPLY (
    SELECT TOP 1 *
    FROM order_logs l2
    WHERE l2.order_id = o.order_id
    ORDER BY log_time DESC
) l

• OUTER APPLY 保证左表行不丢失，等价于 LEFT JOIN
• TOP 1 在子查询内合法，且可带 ORDER BY 控制取哪条
• 注意：子查询里的 WHERE 必须关联到外部 o，否则变成笛卡尔积
• 性能上，若 order_logs(order_id, log_time) 有复合索引，APPLY 可能比 ROW_NUMBER() 更快

为什么不能用 GROUP BY + 聚合函数硬凑？

常见误区：对右表 GROUP BY order_id，再用 MAX(log_time) 拿时间，但这样拿不到对应行的 status 字段——除非用 MAX(status)，可这和“最新日志的状态”不是一回事。

例如两条日志：(log_time='2024-01-01', status='pending') 和 (log_time='2024-01-02', status='shipped')，MAX(log_time) 能拿到时间，但 MAX(status) 返回的是字符串最大值 'shipped'（巧合正确），换成 'cancelled' 和 'shipped' 就错乱了。

所以必须用 ROW_NUMBER() 或 APPLY 这类能“整行选取”的机制，而不是靠聚合函数拼凑字段。

实际写的时候，最容易被忽略的是 ON 条件里漏掉 l.rn = 1 或 APPLY 子查询里没写 WHERE 关联条件——这两处一错，结果要么全空，要么爆炸式重复。