PostgreSQL用jsonb_path_exists查JSON数组是否含某值,需绑定变量且不走索引;MySQL用JSON_CONTAINS实现元素匹配;SQLite需json_each展开;高频查询应建生成列+GIN索引。
jsonb_path_exists 查 JSON 数组是否含某值PostgreSQL 12+ 支持标准 JSON 路径查询,比老式 @> 或 ? 操作符更精准、可读性更好,尤其适合嵌套数组场景。比如字段 tags 是 JSONB 类型,存的是字符串数组 ["sql", "json", "postgres"],要查含 "json" 的记录:
SELECT * FROM posts WHERE jsonb_path_exists(tags, '$[*] ? (@ == $value)', '{"value": "json"}');
注意:第三个参数是绑定变量对象,必须是 JSON 格式;$[*] 遍历数组每个元素,@ == $value 做严格相等判断。
[{"id": 1, "name": "a"}, {"id": 2, "name": "b"}]),可改写为 '$[*] ? (@.name == $value)'
'$[*] ? (@ == "json")')在动态 SQL 中易引发注入,不推荐JSON_CONTAINS 查数组元素MySQL 不支持路径表达式遍历数组,但 JSON_CONTAINS 可以判断某个值是否作为「独立元素」存在于 JSON 数组中(不是子串匹配)。假设 data 字段类型是 JSON,存 ["apple", "banana", "cherry"]:
SELECT * FROM products WHERE JSON_CONTAINS(data, '"banana"', '$');
关键点:JSON_CONTAINS 第二个参数必须是带双引号的 JSON 字符串(即 "\"banana\""),第三个参数是路径,默认 '$' 表示根节点 —— 这里要求根节点本身是数组。
{"colors": ["red", "blue"]},路径就得写 '$.colors'
JSON_CONTAINS(data, '"ban"', '$') 不会命中 "banana"
光靠函数无法提速,得让查询条件能走索引。PostgreSQL 对 jsonb 提供 GIN 索引,但默认只加速 @>、? 等操作符,对 jsonb_path_exists 无效。稳妥做法是用生成列把数组扁平化为 text[],再建 GIN 索引:
ALTER TABLE posts ADD COLUMN tag_list text[] GENERATED ALWAYS AS (ARRAY(SELECT jsonb_array_elements_text(tags))) STORED;
然后建索引:
CREATE INDEX idx_posts_tag_list ON posts USING GIN (tag_list);
之后查就变成标准数组查询:
SELECT * FROM posts WHERE tag_list @> ARRAY['json'];
jsonb_array_elements_text() 把 JSON 数组展开成多行文本,外层 ARRAY(...) 聚合成 PostgreSQL 数组STORED,否则不能建索引tags 时有轻微开销json_each
SQLite 3.38+ 内置 JSON 函数,但没有直接“数组包含”谓词。得用 json_each 把数组展开成虚拟表,再关联查询:
SELECT DISTINCT p.* FROM posts p JOIN json_each(p.tags) j ON 1=1 WHERE j.value = 'json';
这本质是半连接(semi-join),DISTINCT 防止数组多个匹配导致重复行。
json_each 的输出列包括 key、value、type 等,这里只关心 value
tags 可能为 NULL 或非数组,加 AND json_type(p.tags) = 'array' 更安全复杂点在于:不同数据库对 JSON 数组的语义支持差异很大,没有跨库通用写法;即使同个数据库,函数是否走索引、是否支持嵌套、是否区分大小写,都得看具体版本和数据结构。别盲目套用示例里的字段名或路径,先用 SELECT json_typeof(tags), tags FROM ... LIMIT 1 确认实际类型。