PostgreSQL中GIN索引对JSONB字段未生效，因默认jsonb_ops仅支持@>和->>等值查询；应改用jsonb_path_ops或表达式索引如(data->>'status')。
PostgreSQL 中对 JSONB 字段建 GIN 索引为什么没生效？
因为默认的 jsonb_ops 索引只加速 @>、、<code>? 这类“存在性”查询，不支持 -> 或 ->> 后跟具体路径的等值查找。比如你写 WHERE data->>'status' = 'active'，哪怕建了普通 GIN 索引也走不了索引扫描。
实操建议：
- 用
jsonb_path_ops替代默认操作符类：CREATE INDEX idx_data_status ON orders USING GIN (data jsonb_path_ops);
它更紧凑、更快，但只支持@>和?，不支持键路径提取 - 若必须查
->>'status'，改用表达式索引：CREATE INDEX idx_data_status_expr ON orders ((data->>'status'));
注意括号不能少，这是 PostgreSQL 表达式索引语法要求 - 如果字段里 status 值离散度高（比如几百种状态），再加个
WHERE data ? 'status'过滤，避免 NULL 值干扰索引选择
MySQL 8.0 的 JSON 字段能用普通 B-tree 索引吗？
不能直接索引整个 JSON 列，但可以对其中某个路径创建「函数索引」——本质是把 JSON_EXTRACT() 的结果作为虚拟列来索引。
实操建议：
- 先确认 MySQL 版本 ≥ 8.0.13（函数索引支持起点），且表引擎是 InnoDB
- 建索引前必须显式指定路径返回类型，否则会报错：
CREATE INDEX idx_user_type ON users ((CAST(JSON_EXTRACT(profile, '$.type') AS CHAR(20))));
注意双括号和CAST不可省略 - 查询时 WHERE 条件必须严格匹配索引表达式，写成
JSON_EXTRACT(profile, '$.type') = '"admin"'是无效的（多了引号），得用JSON_UNQUOTE(JSON_EXTRACT(...)) = 'admin'或直接用profile->>'$.type' = 'admin'
SQLite 的 JSON1 扩展怎么让 LIKE 查询走索引？
SQLite 本身不支持 JSON 索引，json_extract() 返回的是运行时计算值，无法被 B-tree 索引覆盖。所谓“加速”只能靠预计算 + 普通列索引。
实操建议：
- 别指望在 WHERE 里写
json_extract(data, '$.name') LIKE 'A%'能用上索引——它永远全表扫描 - 真正可行的做法：加一个触发器，在 INSERT/UPDATE 时把
json_extract(data, '$.name')的值自动存进冗余列name_text，然后给这个列建普通索引 - 如果 JSON 结构固定且字段不多，干脆别用 JSON 存，拆成常规字段更稳；JSON1 扩展只适合读多写少、结构动态的场景
SQL Server 的 OPENJSON 性能差，是不是索引没建对？
不是索引问题，是 OPENJSON() 本身每次调用都要解析整段 JSON 字符串，属于 CPU 密集型操作。即使源 JSON 存在已索引的列，OPENJSON 内部仍无缓存、不复用解析结果。
实操建议：
- 避免在 JOIN 或子查询中高频调用
OPENJSON()，尤其不要在 ON 条件里写它 - 如果 JSON 内容稳定，优先用
SELECT ... FROM OPENJSON(@json) WITH (...)一次性展开，而不是嵌套多层APPLY - 真要高频查询特定字段，考虑用计算列 + PERSISTED：
ALTER TABLE logs ADD status AS JSON_VALUE(data, '$.status') PERSISTED;
再给status建索引，这样查询就退化为普通字符串查找
JSON 索引不是“建了就快”，关键在匹配查询模式和索引类型。最容易被忽略的是：不同数据库对 JSON 路径表达式的语法容忍度差异极大，比如 PostgreSQL 用 ->>，MySQL 用 ->> 但要求路径带引号，SQL Server 用 JSON_VALUE() 函数——抄错一个符号，索引就彻底失效。
