必须用窗口函数而非MIN/MAX聚合：FIRST_VALUE(order_time) OVER (PARTITION BY user_id ORDER BY order_time)取首单时间，LAST_VALUE(order_time) OVER (PARTITION BY user_id ORDER BY order_time ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)取末单时间，且需显式指定窗口帧，否则LAST_VALUE行为异常。
用窗口函数找每个用户的首单和末单时间
直接用 MIN() 和 MAX() 按用户聚合会丢失订单顺序信息——比如用户下了 5 单，但你真正要的是「最早那笔订单的下单时间」和「最晚那笔订单的下单时间」，而不是所有订单里全局最早的/最晚的时间戳。正确做法是先按用户+时间排序，再用窗口函数定位每组的第一行和最后一行。
关键点：必须用 ORDER BY order_time 配合 ROW_NUMBER() 或 FIRST_VALUE()/LAST_VALUE()，不能只靠聚合函数。
-
FIRST_VALUE(order_time) OVER (PARTITION BY user_id ORDER BY order_time ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)—— 注意必须加ROWS BETWEEN ...，否则默认窗口是ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，LAST_VALUE就会出错 - 更稳妥写法是用两次
ROW_NUMBER()：一次升序标最小时间，一次降序标最大时间，再用条件聚合或子查询过滤 - 如果数据库不支持
FIRST_VALUE（如旧版 MySQL），就用自连接或相关子查询，但性能差很多
MySQL 8.0+ 的简洁写法
MySQL 8.0 起支持完整窗口函数，可以直接写：
SELECT DISTINCT user_id, FIRST_VALUE(order_time) OVER (PARTITION BY user_id ORDER BY order_time) AS first_order_time, LAST_VALUE(order_time) OVER (PARTITION BY user_id ORDER BY order_time ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS last_order_time FROM orders;
注意：LAST_VALUE 必须显式声明窗口范围，否则返回的是当前行的值；DISTINCT 是因为窗口函数会让每行都输出，需去重。
- 如果
order_time有重复，FIRST_VALUE返回的是排序后第一个出现的值（稳定），但不保证是物理第一行 - 想同时拿到首单/末单的订单 ID 或金额？把对应字段也放进
FIRST_VALUE()里即可，例如FIRST_VALUE(order_id) - 避免在 WHERE 中提前过滤掉部分订单——窗口函数执行在 WHERE 之后，但如果你 WHERE 掉了某用户的部分订单，会影响“首/末”的判定结果
兼容老版本 MySQL（5.7）的替代方案
没有窗口函数时，得靠关联子查询或 JOIN。典型写法是先算出每个用户的极值时间，再连回原表取完整记录：
SELECT t1.user_id,
t2.min_time AS first_order_time,
t3.max_time AS last_order_time
FROM (SELECT DISTINCT user_id FROM orders) t1
LEFT JOIN (SELECT user_id, MIN(order_time) AS min_time FROM orders GROUP BY user_id) t2
ON t1.user_id = t2.user_id
LEFT JOIN (SELECT user_id, MAX(order_time) AS max_time FROM orders GROUP BY user_id) t3
ON t1.user_id = t3.user_id;
这个写法只拿到时间，拿不到对应订单的其他字段；如果还要 order_id 或 amount，就得用相关子查询，或者用 GROUP_CONCAT + SUBSTRING_INDEX 黑科技（不推荐，易出错）。
- 性能隐患：子查询对大表可能触发多次全表扫描，建议在
(user_id, order_time)上建联合索引 - 如果有多个订单时间相同（比如同一秒下单），
MIN/MAX无法区分哪一笔是实际首单，这时必须依赖主键或自增 ID 排序 - 别用
ORDER BY order_time LIMIT 1做相关子查询——MySQL 5.7 不允许在子查询中对关联表排序后 LIMIT
PostgreSQL 和 SQL Server 的注意事项
PostgreSQL 对 LAST_VALUE 的默认窗口行为和 MySQL 一致，同样需要显式指定 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING；SQL Server 则从 2012 起就支持标准窗口语法，但要注意 LAST_VALUE 在 ORDER BY 相同时的行为：它返回该排序组内最后一行的值，不是“最后一条记录”，所以如果时间相同，结果取决于表的物理顺序或主键隐式排序。
- 想严格按插入顺序定首末单？确保
order_time字段精度足够（比如用TIMESTAMP(6)），或额外依赖id字段做二级排序：ORDER BY order_time, id - 空值处理：
order_time IS NULL的订单会被排在最前（默认），影响FIRST_VALUE结果，建议在 WHERE 中提前排除或用COALESCE(order_time, '9999-12-31')控制位置 - 分区键必须是确定性列，不能是表达式或函数结果（如
PARTITION BY YEAR(order_time)在多数引擎中非法）
