SQL 聚合成数组为什么顺序会变？外层 ORDER BY 能管住数组内部吗？
面试怎么回答
我会先区分最终结果行排序和聚合内部排序。需要行为序列时，应在支持的聚合语法里指定事件时间及稳定并列键；外层ORDER BY不能决定数组内部。相关字段应聚合为同一对象，防止数组错位，还要约定NULL、重复事件和空集合语义。对超长序列应保留明细或明确截断规则，而不是无限堆到一个数组。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
同一段SQL昨天得到“浏览、加购、支付”，今天变成“支付、浏览、加购”。事件一条没少，只是数组位置变了，下游却把第一个元素当成用户的首次行为。
结果行顺序与聚合元素顺序是两层语义；需要稳定序列时，要在聚合内部声明完整排序，并把相关字段作为整体保存。
外层排序只决定哪一行先返回
按用户分组后，每个用户得到一个数组。查询最外层的ORDER BY user_id，决定用户甲的结果行是否排在用户乙之前，不能决定甲的数组内部哪个事件在前。
没有明确顺序约束时，聚合接收到的输入顺序可能受执行计划、并行度与数据分布影响。某次恰好按时间排列，不等于语义上已经保证按时间排列。
因此不能拿几次运行结果相同，证明数组天然有序。顺序是需要写进查询的要求，不是从当前执行现象反推出的契约。
在聚合内部表达组内顺序
以下按PostgreSQL 17语法展示，假设event_id已去重，且在同一用户内可以稳定打破时间并列：
SELECT user_id,
JSONB_AGG(
JSONB_BUILD_OBJECT(
'event_id', event_id,
'event_time', event_time,
'action', action
)
ORDER BY event_time, event_id
) AS event_path
FROM clean_events
GROUP BY user_id
ORDER BY user_id;聚合内部按事件时间和事件ID组织元素，外层按用户排列结果行。其他引擎可能采用不同函数或先聚合结构体再排序的方式，应根据对应语法实现相同语义。
稳定并列键也不等于真实业务先后。同一毫秒内两个动作如果必须有因果顺序，应保留来源序号；任意事件ID只能提供确定的展示顺序，不能制造不存在的业务证据。
多个数组分别聚合，为什么危险？
假设action数组过滤掉NULL，event_time数组却保留所有记录，两者长度和位置就可能失去对应关系。即使都有ORDER BY，如果排序键或过滤条件不一致，同样可能错位。
把同一事件的字段先打包成一个对象，再聚合对象，可以保留行内配对关系。需要过滤事件时，以事件整体为单位处理，不要各字段独立决定是否保留。
NULL与空数组也要明确。没有输入行时，某些聚合返回NULL；如果接口约定返回空数组，应做显式转换。用户本来没有事件，与关联失败导致未找到事件，也未必应该直接合并成同一种状态。
去重与排序的先后不能含糊
重复上报的事件可能让路径多出一个动作。应先按可靠事件身份去重，再组织序列，不能简单对action去重：同一个用户合法地浏览两次，动作名称相同但事件不同。
若只展示前若干事件，要说明按哪个顺序截取、并列如何处理，以及是否保留总事件数和截断标识。展示截断不应被下游误认为完整行为路径。
超长数组还会给聚合内存、结果传输和消费方解析带来压力。分区调得更多，也无法把一个必须聚合到单个用户结果里的超长对象无限拆开。
一个典型场景：首次行为突然变成支付
比如报表从聚合数组里取第一项作为首次行为，早期小数据测试都按文件原顺序返回。数据增多后执行计划变化，部分用户首次行为变成了支付，团队首先怀疑事件时间解析错了。
实际原始时间正确，只是聚合没有声明内部排序。旧验收比较事件总数和动作集合，两者都一致，却没有检查序列位置。
修正时增加组内完整排序，把事件打包聚合，并用乱序输入、同时间戳、NULL字段和重复事件做回归。首次行为指标则直接根据同一排序规则挑选事件，避免从未定义顺序的集合里推导先后。
有序序列、无序集合和去重集合是不同数据结构。面试回答时先说清需要哪一种，再选函数，往往比背某个聚合语法更关键。
资料与适用边界
机制以所链接版本为准；业务示例用于说明判断方法，不代表作者真实项目或已验证的生产性能。