UNNEST不能直接用于UPDATE的SET子句，必须配合FROM子句与原表关联更新；正确用法是通过FROM(SELECT*FROMUNNEST(ARRAY[...],ARRAY[...])ASt(id,val))ASdataWHERE原表.id=data.id实现批量安全更新。
UNNEST 不能直接用于 UPDATE 语句
PostgreSQL 的 UPDATE 语法不支持把 UNNEST 当作数据源直接写在 SET 或 FROM 子句里（比如 UPDATE t SET x = UNNEST(...) 会报错）。你真正能用的，是把 UNNEST 和 VALUES 或子查询一起配合 FROM 子句做关联更新。
用 FROM + UNNEST 实现批量更新（推荐做法）
核心思路：把要更新的 ID 和新值分别构造成数组，用 UNNEST 展开成行集，再通过 JOIN 关联原表。必须确保两个数组长度一致且顺序严格对应，否则结果不可控。
常见错误现象：ERROR: more than one row returned by a subquery used as an expression（说明没走 FROM 关联，误用了标量子查询）；或更新了错误的行（数组错位）。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 使用场景：从应用层传入一批 ID 和对应的新状态、价格、时间戳等，需原子性更新
- 示例（更新 users 表的 status 字段）：
UPDATE users u SET status = data.new_status FROM (SELECT * FROM UNNEST(ARRAY[101, 102, 103], ARRAY['active', 'inactive', 'pending']) AS t(id, new_status)) AS data WHERE u.id = data.id;
-
UNNEST多个数组时，PostgreSQL 按位置一一配对，不是笛卡尔积 —— 这点和VALUES行构造器行为一致 - 性能影响：数组长度超过几千时，建议分批（如每 1000 行一次），避免 plan 缓存失效或内存压力
为什么不用 WITH + UNNEST 再 UPDATE？
有人尝试先用 WITH 把 UNNEST 结果命名，再在 UPDATE 中引用，但 PostgreSQL 不允许在 UPDATE ... FROM 的 FROM 子句里直接引用 CTE 别名（会报 relation "xxx" does not exist）。必须把 CTE 写进 FROM 子查询内部，或者改用 VALUES。
更安全的替代写法（尤其兼容老版本）：
UPDATE users u SET status = v.new_status FROM (VALUES (101, 'active'), (102, 'inactive'), (103, 'pending')) AS v(id, new_status) WHERE u.id = v.id;
-
VALUES可读性更高，调试时容易一眼看出映射关系 -
UNNEST优势只在“数组由程序动态拼接”时（比如从 JSON 解析出两个同长数组） - 如果数组来自函数返回（如
string_to_array），务必加COALESCE或NULLIF防空数组，否则UNNEST返回零行，整个 UPDATE 不生效却无提示
更新时带条件过滤（比如只更新未删除的记录）
在 FROM 子句展开后，WHERE 条件仍作用于原表，所以可以安全叠加业务逻辑。但注意：过滤条件不能写在 UNNEST 子查询里，否则可能漏掉本该更新的行（因为 UNNEST 已固定输出行数）。
- 正确写法：把
u.deleted_at IS NULL放在主WHERE后，和u.id = data.id并列 - 错误写法：
FROM (SELECT ... FROM UNNEST(...) WHERE ...)—— 这会先筛掉部分UNNEST行，导致关联断裂 - 若需跳过某些 ID（比如权限校验失败），应在应用层预过滤数组，而不是靠 SQL 过滤
UNNEST输出
数组顺序对齐和空值防御是实际写这类语句时最容易被忽略的两处。一旦出错，往往表现为“部分行没更新”或“更新到错误 ID”，而日志里看不到明显报错。
