UNNEST是PostgreSQL、BigQuery、Trino等数据库支持的非标准函数/操作符，用于将数组展开为多行；MySQL、SQL Server、SQLite原生不支持，Oracle用TABLE()模拟。
UNNEST 是什么，它在哪些数据库里能用
UNNEST 不是 SQL 标准函数，而是 PostgreSQL、BigQuery、Trino（PrestoSQL）等少数引擎支持的特有函数。MySQL、SQL Server、SQLite 原生不支持 UNNEST；Oracle 用 TABLE() 模拟类似行为，但语法和语义不同。如果你执行 SELECT * FROM UNNEST(ARRAY[1,2,3]) 报错，先确认当前数据库是否支持——最直接的办法是查文档或运行 SELECT version(); 看引擎类型。
PostgreSQL 中 UNNEST 的基本用法和常见错误
PostgreSQL 的 UNNEST 接收一个数组（ARRAY 或字面量），返回一行一列的结果集。但容易踩的坑是：它默认不保留原始行上下文，也不保证顺序稳定（除非显式加 WITH ORDINALITY）。
常见错误现象：
- 用
SELECT id, UNNEST(tags) FROM posts;时，如果某行tags是NULL，整行会消失（UNNEST(NULL)返回空结果集） - 多个数组一起
UNNEST（如UNNEST(arr1, arr2)）要求长度严格一致，否则报错ERROR: arrays must have the same length - 没加
WITH ORDINALITY就想按原顺序取索引，结果顺序不可靠
正确写法示例：
SELECT id, tag, idx FROM posts CROSS JOIN LATERAL UNNEST(tags) WITH ORDINALITY AS t(tag, idx) WHERE tags IS NOT NULL;
这里用 CROSS JOIN LATERAL 替代老式逗号连接，确保每行独立展开；WHERE tags IS NOT NULL 显式过滤掉空数组行，避免意外丢数据。
BigQuery 中 UNNEST 的行为差异与注意事项
BigQuery 的 UNNEST 是 FROM 子句中的关键字，不是函数，语法必须是 FROM table_name, UNNEST(column_name) 或 FROM UNNEST([1,2,3])。它天然支持 NULL 数组（跳过不展开），但不支持 WITH ORDINALITY，要序号得用 OFFSET 或 ROW_NUMBER() 配合 ARRAY_LENGTH。
关键差异点：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 不能写
SELECT UNNEST(my_array)—— 这会报错UNNEST operator must be used in FROM clause - 多列数组同时展开需用
UNNEST(ARRAY_CONCAT(...))合并，不能像 PostgreSQL 那样传多个参数 - 嵌套结构（如
ARRAY）展开后字段自动扁平化，> SELECT * FROM UNNEST(nested_arr)直接得到name和value两列
安全写法示例：
SELECT id, tag.name, tag.value FROM my_table, UNNEST(tags) AS tag WHERE ARRAY_LENGTH(tags) > 0;
替代方案：没有 UNNEST 时怎么模拟数组展开
在 MySQL 或 SQL Server 这类不支持 UNNEST 的系统中，只能靠递归 CTE（MySQL 8.0+、SQL Server）或数字表 + 字符串分割实现。但性能差、可读性低，且对长数组极易超限。
典型限制：
- MySQL 的
JSON_TABLE可处理 JSON 数组，但要求字段存为 JSON 类型，且不支持原生数组列 - SQL Server 的
STRING_SPLIT只能拆字符串，需先CONCAT('[', ..., ']')再解析，丢失类型信息 - 所有模拟方式都无法高效处理多维数组或嵌套结构
所以，如果业务频繁需要数组展开，优先考虑迁移到支持 UNNEST 的引擎，而不是硬写兼容层——尤其当数组长度超过百项或涉及并发更新时，模拟方案的锁表现和执行计划往往不可控。
真正麻烦的不是语法怎么写，而是展开后如何关联回原始主键、怎么处理 NULL 和空数组、以及是否需要保序——这些细节一旦漏掉，查出来的数据就 quietly 错了。
