array查询更轻量稳定，但jsonb支持嵌套、动态字段和混合类型；性能取决于查询模式：固定索引用array，路径或键值过滤用jsonb索引。
PostgreSQL 里存列表数据，ARRAY 和 JSONB 哪个更快？
多数情况下，ARRAY 查询更轻量、更稳定；但只要涉及嵌套结构、字段动态增减或混合类型，JSONB 就不可替代。性能差距不是“谁绝对快”，而是“谁在什么条件下不拖后腿”。
关键看查询模式：如果只做 IN 匹配、顺序访问、固定索引取值（比如 tags[1]），ARRAY 的开销几乎为零；一旦要查 WHERE tags @> '["urgent"]' 或按 JSON 内某个 key 过滤（如 data->>'status'），JSONB 的 GIN 索引才能真正起效，而 ARRAY 在这类场景下要么写一堆 UNNEST，要么干脆扫全表。
-
ARRAY类型强制同构（所有元素必须同类型），写入校验快，但改 schema 成本高 -
JSONB允许任意嵌套和类型混用，但每次读取都要解析二进制结构，小字段差异不大，大对象（>4KB）明显变慢 - 索引策略不同：
ARRAY靠GIST或GIN支持包含/重叠查询，JSONB靠GIN（默认操作符类）或表达式索引支持路径查询
什么时候必须用 JSONB 而不能硬套 ARRAY？
当你的“数组”其实是个半结构化记录集合——比如日志事件列表、多语言文案、带元数据的标签组——ARRAY 就撑不住了。它没法表达 [{"lang": "zh", "text": "你好"}, {"lang": "en", "text": "Hello"}] 这种结构，强行 flatten 成二维数组会丢失语义关联。
- 字段名不固定：今天加
"priority"，明天加"expires_at"，ARRAY没法描述这种变化 - 单条记录含多种类型：一个元素里既有
string又有number还有null，ARRAY要求统一类型，只能全转成TEXT，查的时候还得手动 cast - 需要按内部 key 建索引：比如高频查
WHERE data->>'category' = 'error'，这时建表达式索引CREATE INDEX ON logs ((data->>'category'))才实际有效
ARRAY 查询踩坑：别信 ANY 万能，小心隐式转换和 NULL
ANY 看似方便，但遇上 NULL 或类型不匹配就静默失效。比如 WHERE 'foo' = ANY(tags)，如果 tags 是 TEXT[] 而传入的是 CHAR 字面量，在某些 collation 下可能不命中。
- 显式声明类型：写成
'foo'::TEXT = ANY(tags)，避免隐式 cast 导致索引失效 -
ARRAY包含NULL时，NOT ('x' = ANY(arr))不等价于'x' ALL(arr)——前者遇到NULL返回NULL（即 false），后者才真正表达“全部不等于” - 想查“是否包含某值”又怕 NULL 干扰，优先用
arr @> ARRAY['x']::TEXT[]（需 GIN 索引），语义清晰且可索引
JSONB 性能瓶颈常不在存储，而在查询写法
很多人抱怨 JSONB 慢，其实 80% 是因为写了 WHERE data->>'field' = 'val' 却没建对应表达式索引，或者滥用 jsonb_path_exists 扫全量解析。
- 路径查询必须配索引：例如常用
data->>'status'，就得建CREATE INDEX ON tbl ((data->>'status'))；用data->'meta'->>'score'就得对应写((data->'meta'->>'score')) - 避免在 WHERE 里调用函数解析整个 JSON：比如
WHERE (data->'items')::JSONB @> '[{"id":123}]'，不如提前把关键字段冗余到普通列，或用生成列 + 索引 -
JSONB的CONTAINS（@>）比EXISTS（?）开销大，前者要深度比对结构，后者只查 key 存在性
最易被忽略的一点：JSONB 的大小直接影响 WAL 日志体积和复制延迟。一个 1MB 的 JSONB 字段更新，哪怕只改了一个字符，也会写入完整新值——而 ARRAY 同样更新通常更紧凑。线上高吞吐写入场景，这点会悄悄卡住主从同步。
