视图中STRING_AGG结果“飘”是因为未显式指定ORDER BY，导致拼接顺序不固定；必须在视图定义中固化排序、空值处理和分组逻辑，否则同一查询可能返回不同顺序的结果。
视图里用 STRING_AGG 没问题，但直接封装复杂拼接容易出错——关键在于排序、空值和分组逻辑必须显式固化，否则视图结果不可复现。
为什么视图里 STRING_AGG 的结果会“飘”
视图本身不保存执行计划，也不强制排序。如果只写 STRING_AGG(name, ',') 而没加 ORDER BY，PostgreSQL 或 SQL Server 都不会保证拼接顺序。同一视图反复查询，可能得到 张三,李四 或 李四,张三 ——尤其在并行执行或数据页物理顺序变化时。
- 错误示例：
CREATE VIEW user_tags AS SELECT user_id, STRING_AGG(tag, ',') FROM user_tag GROUP BY user_id;→ 结果不稳定 - 正确做法：必须把排序写进视图定义里，比如
STRING_AGG(tag, ',' ORDER BY tag) - SQL Server 和 PostgreSQL 语法一致，但 Databricks 还支持
NULLS FIRST等扩展，跨平台时要留意
视图中处理空字符串和 NULL 的陷阱
STRING_AGG 默认跳过 NULL，但对空字符串 '' 照单全收，拼出来就是 北京,,上海 这种带多余分隔符的脏数据。
- 用
CASE WHEN把空字符串转成NULL：STRING_AGG(CASE WHEN tag = '' THEN NULL ELSE tag END, ',' ORDER BY tag) - 别在视图外再套一层
FILTER (WHERE tag IS NOT NULL)—— 多余且可能误删本该保留的空格字符串（如' '） - 如果字段类型是
TEXT，PostgreSQL 下STRING_AGG输出也是TEXT；SQL Server 则按输入类型推导为nvarchar，注意长度溢出风险
多层嵌套子查询在视图里怎么安全用 STRING_AGG
常见需求：查用户 + 他关联的所有角色名 + 最近三次登录时间。这类场景常在视图里嵌套子查询，但容易漏掉内层 GROUP BY 或排序。
- 子查询里必须有明确
GROUP BY，否则STRING_AGG会报错：“column must appear in the GROUP BY clause” - 排序必须写在子查询内部的
STRING_AGG里，不能指望外层ORDER BY控制拼接顺序 - 示例（PostgreSQL）：
CREATE VIEW user_summary AS SELECT u.id, u.name, (SELECT STRING_AGG(r.role_name, '｜' ORDER BY r.created_at DESC) FROM user_role r WHERE r.user_id = u.id) AS roles, (SELECT STRING_AGG(TO_CHAR(l.login_time, 'YYYY-MM-DD'), ',' ORDER BY l.login_time DESC LIMIT 3) FROM user_login l WHERE l.user_id = u.id) AS recent_logins FROM users u;
性能与维护提醒：别让视图变成“黑盒聚合”
视图一旦封装了 STRING_AGG，它就不再是简单映射，而是实时聚合。如果底层表数据量大，每次查视图都会触发全量分组和字符串拼接。
- 避免在视图里对未索引字段做
ORDER BY，比如STRING_AGG(name, ',' ORDER BY UPPER(name))无法走索引 - 如果拼接结果只用于展示且更新不频繁，考虑用物化视图（PostgreSQL 14+）或定时任务写入汇总表
- Databricks 中
string_agg支持DISTINCT和FILTER，但 SQL Server 不支持DISTINCT参数，跨平台迁移前务必验证
最常被忽略的一点：视图定义里的 STRING_AGG 排序子句，必须和业务语义对齐。比如“按创建时间倒序”和“按字母升序”输出的字符串，下游应用解析逻辑很可能完全不同——这不是语法问题，而是契约问题。
