UNNEST函数将数组展开为多行，但不保证原始顺序，需用WITH ORDINALITY保留索引；不支持多维数组直接展开，空数组或NULL会导致行丢失，应配合LATERAL和LEFT JOIN确保完整性。
UNNEST函数会把数组转成多行，但默认不保留原始顺序
直接用 UNNEST 会打乱原有索引顺序，尤其在做特征向量、时间序列或带位置语义的数组时，这会导致结果错位。比如 ARRAY[10, 20, 30] 经 UNNEST 后可能返回 20、10、30 —— 实际上 PostgreSQL 12+ 默认按内存布局输出，不保证顺序，除非显式排序或关联下标。
正确做法是配合 WITH ORDINALITY：
SELECT value, ord FROM UNNEST(ARRAY['a','b','c']) WITH ORDINALITY AS t(value, ord);
返回三行：value='a', ord=1；value='b', ord=2；value='c', ord=3。这个 ord 就是原始位置，比手动 array_position 稳定得多。
UNNEST不能直接用于多维数组，必须先降维或指定维度
对二维数组如 text[][] 直接调用 UNNEST 会报错：ERROR: cannot unnest array of arrays。PostgreSQL 不支持原生展开嵌套结构。
常见应对方式有：
- 用
UNNEST+ARRAY构造器逐层展开：先UNNEST外层数组得到子数组，再对每个子数组再次UNNEST - 改用
unnest(array, array)的双参数形式（仅限一维）：传入两个同长数组，自动按位置配对，适合「值+标签」并行展开 - 对固定维度数组（如
INTEGER[3][3]），先用array_length和generate_subscripts手动构造坐标，再取值
例如处理 schedule TEXT[][] 字段：
SELECT s[1], s[2] FROM sal_emp, LATERAL UNNEST(schedule) AS s;
这里 LATERAL 是关键，它让内层能引用外层的 schedule，而 s 是每行展开后的一维子数组。
UNNEST和JOIN一起用时，空数组会丢行
如果某条记录的数组字段是 NULL 或空数组 '{}'，用 UNNEST 做 INNER JOIN 或隐式 FROM 关联时，该行直接消失 —— 这不是 bug，是 SQL 的语义：集合为空，连接无匹配项。
要保留原始行，必须改用 LEFT JOIN LATERAL：
SELECT e.name, u.skill FROM employee e LEFT JOIN LATERAL UNNEST(e.skills) AS u(skill) ON true;
这样即使 e.skills 是 NULL 或 '{}'，e.name 仍会输出一行，u.skill 为 NULL。
注意：不能写成 LEFT JOIN UNNEST(...) ON true，必须是 LATERAL，否则报错 invalid reference to FROM-clause entry。
大批量UNNEST可能触发TOAST解压开销
当数组存于 TOAST 表（即 >2KB）时，每次 UNNEST 都需整块解压，哪怕你只取前 3 个元素。这对高频查询或大特征向量（如 1000 维 float[]）影响明显。
可优化的点：
- 若只需判断存在性，别用
UNNEST，改用@>或= ANY() - 若只取前 N 项，加
LIMIT N，但注意：必须放在UNNEST的子查询里，不能放最外层 —— PostgreSQL 会先全展开再截断 - 对只读场景，考虑用物化视图预展开，避免每次重复计算
比如只查每个用户前 5 个技能：
SELECT name, skill FROM ( SELECT name, UNNEST(skills) AS skill FROM employee ) t LIMIT 5;
这会先展开全部再取 5 行；正确写法是：
SELECT name, skill FROM employee, LATERAL ( SELECT UNNEST(skills) LIMIT 5 ) AS t(skill);
UNNEST 的真正难点不在语法，而在理解它和存储模型、执行计划、NULL 语义的耦合关系。一个没加 LATERAL 的 LEFT JOIN，一次漏掉的 WITH ORDINALITY，都可能让分析结果偏移 —— 这些细节不会报错，但会让数据失真。
