直接用min(order_time)只能获取最小时间值，无法保证关联其他字段来自同一订单行；正确方法是用row_number()窗口函数按user_id分组、order_time排序后取rn=1的整行记录。
为什么直接用 MIN(order_time) 只能拿到时间，拿不到完整订单行
这是最常见的误解：以为 SELECT user_id, MIN(order_time) FROM orders GROUP BY user_id 能返回“每个用户最早那笔订单的全部字段”，实际上它只保证 order_time 是最小值，其他列（比如 order_id、amount）来自哪一行完全不确定——MySQL 5.7+ 默认拒绝这种非确定性查询，会报错 ERROR 1055；老版本或宽松模式下则可能随机返回某一行的值，结果不可靠。
正确做法：用窗口函数 ROW_NUMBER() 标记首次下单
真正要取“整行记录”，得先按用户分组、按时间排序，再筛选序号为 1 的行。标准写法如下：
SELECT user_id, order_id, order_time, amount
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time ASC) AS rn
FROM orders
) t
WHERE rn = 1;
注意点：
-
PARTITION BY user_id确保每个用户独立编号 -
ORDER BY order_time ASC保证最早时间排第一；如果存在相同时间，可追加order_id避免不确定性：ORDER BY order_time, order_id - PostgreSQL / SQL Server / MySQL 8.0+ / Oracle 都支持该语法；SQLite 3.25+ 也支持
兼容旧版 MySQL（5.7 及以下）的替代方案
若无法升级或用的是旧版 MySQL，可用自连接或子查询模拟：
SELECT o1.user_id, o1.order_id, o1.order_time, o1.amount FROM orders o1 WHERE o1.order_time = ( SELECT MIN(o2.order_time) FROM orders o2 WHERE o2.user_id = o1.user_id );
但要注意：
- 如果同一用户有多个订单时间并列最早，这条语句会返回所有并列记录（即“首次下单”可能不止一条）；而
ROW_NUMBER()方案默认只取一条（可配合ORDER BY ... LIMIT 1控制） - 性能上，子查询在数据量大时可能较慢，建议给
(user_id, order_time)建联合索引 - 不能用
GROUP BY+MIN()直接拼其他字段，否则仍是非标准行为
别忽略空值和重复时间带来的歧义
order_time 为空（NULL）时，MIN() 会忽略它，ROW_NUMBER() 默认把 NULL 排在最前（取决于数据库排序规则），这可能导致误判“首次下单”。实际使用前务必确认：
- 是否允许
order_time IS NULL？如不允许，建表时应加NOT NULL约束 - 是否存在测试数据或异常订单导致时间重复？如有，需明确业务规则：是任选一条，还是按
order_id最小为准 - 时间精度是否一致？比如有的用
DATETIME，有的用TIMESTAMP，微秒级差异可能影响排序稳定性
真实场景里，首次下单逻辑往往还涉及状态过滤（比如只统计 status = 'paid' 的订单），这些条件必须写在最内层查询中，而不是 WHERE 外层，否则会改变分组基准。
