PostgreSQL用jsonb_path_exists查JSON数组是否含某值，需绑定变量且不走索引；MySQL用JSON_CONTAINS实现元素匹配；SQLite需json_each展开；高频查询应建生成列+GIN索引。
PostgreSQL 中用 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 中易引发注入，不推荐 - 该函数走不到索引，如需高频查询，得配合生成列 + GIN 索引（见下节）
MySQL 8.0 用 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" - 性能一般：每次调用都要解析 JSON，无索引支持；高频场景建议冗余字段或生成列
给 JSON 数组建 GIN 索引加速查询（PostgreSQL）
光靠函数无法提速，得让查询条件能走索引。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时有轻微开销
SQLite 中解析 JSON 数组要绕道 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 确认实际类型。
