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