UNNEST函数将数组展开为多行，但不保证原始顺序，需用WITH ORDINALITY保留索引；不支持多维数组直接展开，空数组或NULL会导致行丢失，应配合LATERAL和LEFT JOIN确保完整性。
UNNEST函数会把数组转成多行，但默认不保留原始顺序
直接调用UNNEST，结果可能会让你感到意外：它常常会打乱数组原有的索引顺序。在处理特征向量、时间序列这类对位置极其敏感的数据时，顺序错位就意味着结果完全失真。比如，你以为ARRAY[10, 20, 30]展开后会是10、20、30，但实际返回的可能是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关联时，这一行数据会直接消失。这并非系统漏洞，而是符合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解压开销
当数组数据过大（超过2KB）被存储到TOAST表中时，每一次UNNEST操作都可能触发整块数据的解压，即使你只需要前几个元素。对于高频查询或处理大维度特征向量（比如1000维的float[]）的场景，这种开销不容小觑。
可以考虑从以下几个方向进行优化：
- 如果仅仅需要判断元素是否存在，就不要用
UNNEST，改用@>（包含）操作符或= ANY()表达式。 - 如果只需要前N项，记得加上
LIMIT N。但要注意：这个LIMIT必须放在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关键字，一次忘记添加的WITH ORDINALITY，都可能让最终的分析结果在静默中发生偏移——这些细节通常不会引发报错，却足以导致数据失真。这才是关键所在。
