用ROW_NUMBER()可精准获取每个客户首笔订单完整记录，需按customer_id分组、order_date和order_id排序；不支持窗口函数时可用NOT EXISTS查无更早订单的记录。
用 ROW_NUMBER() 窗口函数定位首笔订单
直接用 GROUP BY 或 MIN(order_date) 无法可靠取到「每个客户首笔订单的完整记录」，因为最小日期可能对应多条记录，或你还需要其他字段（如 order_id、amount）。最稳的方式是用 ROW_NUMBER() 按客户分组、按时间排序打序号，再筛出序号为 1 的行。
实操建议：
- 确保排序字段明确：优先用
order_date，若存在同秒下单，必须加入唯一字段（如order_id）避免排序不稳定，例如ORDER BY order_date, order_id - 别在子查询里漏写
PARTITION BY customer_id，否则整个表只排一次序，得不到每个客户的“首笔” - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 也支持，但旧版不支持窗口函数
SELECT order_id, customer_id, order_date, amount
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY order_date, order_id
) AS rn
FROM orders
) t
WHERE rn = 1;
用 NOT EXISTS 替代方案（兼容老版本数据库）
如果数据库不支持窗口函数（比如 MySQL 5.7 或早期 SQL Server），NOT EXISTS 是最常用且语义清晰的替代方式：查出「不存在更早订单」的记录。
注意点：
- 子查询中的关联条件必须严格：外层
o1.customer_id = o2.customer_id且o2.order_date ，缺一不可 - 性能上，需确保
(customer_id, order_date)有联合索引，否则全表扫描代价高 - 若存在
NULL的order_date，会被排除——多数业务中这是合理行为，但需确认数据质量
SELECT o1.order_id, o1.customer_id, o1.order_date, o1.amount
FROM orders o1
WHERE NOT EXISTS (
SELECT 1
FROM orders o2
WHERE o2.customer_id = o1.customer_id
AND o2.order_date < o1.order_date
);
为什么不能只用 GROUP BY + MIN()？
常见错误是写成：SELECT customer_id, MIN(order_date), order_id, amount FROM orders GROUP BY customer_id。这会触发 SQL 标准错误（如 PostgreSQL 报错 column "order_id" must appear in the GROUP BY clause），或 MySQL 在 sql_mode=only_full_group_by 下直接拒绝执行。
根本原因：聚合后非分组字段值是未定义的，数据库无法保证 order_id 和 MIN(order_date) 来自同一行。即使侥幸跑通，结果不可靠。
- MySQL 5.7 默认开启
only_full_group_by，强制校验；新版本仍默认启用 - 强行关掉该模式（不推荐）会让
order_id取到任意一条记录的值，大概率不是首笔订单的order_id - 想“安全取整行”，就必须把筛选逻辑放在行级（窗口函数或相关子查询），而不是列级聚合
遇到重复时间戳时的真实影响
订单系统若用应用层生成时间（尤其批量导入或高并发场景），order_date 可能大量重复。此时仅按时间排序，ROW_NUMBER() 会随机分配序号（取决于底层执行计划），导致每次查询结果不一致。
解决办法只有两个：
- 在
ORDER BY中追加确定性字段，首选主键order_id（自增或 UUID 均可），次选created_at（毫秒精度时间戳） - 业务侧控制写入：插入前检查并微调时间戳，或用数据库序列生成严格单调的序号字段（如 PostgreSQL 的
serial）
没加兜底排序字段的 ROW_NUMBER() 查询，在生产环境反复执行可能返回不同记录，这点容易被忽略，但直接影响对账和报表准确性。
