JSON_CONTAINS查得慢是因为全表扫描+JSON解析+内存遍历，无法使用B+树索引；JSON_SEARCH同样不能走索引，且更耗资源；提速应提取关键字段建生成列加索引或拆表。
JSON_CONTAINS 为什么查得慢？
JSON_CONTAINS 在 MySQL 中本质是全表扫描 + JSON 解析 + 内存遍历，即使字段上有普通索引也完全用不上。它不支持 B+ 树索引加速，因为 JSON 值是文本序列化存储，MySQL 无法预知结构、路径或值分布。
- 如果
json_col是MEDIUMTEXT或LONGTEXT类型，每次调用都要完整加载并解析整个 JSON 文档，内存和 CPU 开销陡增 - 当匹配路径较深（如
$.data.items[0].tags[2]）时，解析开销进一步放大 - 多层嵌套数组 +
JSON_CONTAINS配合OR条件，很容易触发临时表 + filesort
实测：10 万行数据，json_col 平均大小 2KB，单次 JSON_CONTAINS(json_col, '"active"', '$.status') 查询耗时常超 800ms；加了普通索引毫无改善。
JSON_SEARCH 能走索引吗？
不能。JSON_SEARCH 同样无法利用 B+ 树索引，而且比 JSON_CONTAINS 更脆弱：它返回的是匹配路径字符串（如 "$.items[1].name"），不是布尔值，无法被优化器提前剪枝。
-
JSON_SEARCH(json_col, 'one', 'admin')会逐字段做子串匹配（含引号、转义），实际行为接近LIKE '%\"admin\"%'，但更重 - 若指定
'all'模式，MySQL 必须遍历全部键值对，无法短路退出 - 在
WHERE子句中使用JSON_SEARCH IS NOT NULL，执行计划仍显示type: ALL（全表扫描）
注意：JSON_SEARCH 对大小写敏感，且不会自动忽略空格或换行——JSON 文本里多一个缩进空格，就可能匹配失败。
真正能提速的替代方案
核心原则：把 JSON 里的关键查询字段“拎出来”，单独建索引列。
- 使用生成列（Generated Column）提取常用字段，再加索引：
ALTER TABLE users ADD status VARCHAR(20) AS (JSON_UNQUOTE(JSON_EXTRACT(profile, '$.status'))) STORED; ALTER TABLE users ADD INDEX idx_status (status);
- 对数组类场景（如标签列表），拆成关联表更可靠：
-- 不要用 JSON_CONTAINS(tags, '"vue"') -- 改用： CREATE TABLE user_tags (user_id BIGINT, tag VARCHAR(50), PRIMARY KEY(user_id, tag)); SELECT u.* FROM users u JOIN user_tags t ON u.id = t.user_id WHERE t.tag = 'vue';
- 如果必须用 JSON 查询，优先选
->>（即JSON_EXTRACT + JSON_UNQUOTE）配合等值比较，它比JSON_CONTAINS略快，且可配合函数索引（MySQL 8.0.13+）：ALTER TABLE logs ADD status_v VARCHAR(20) AS (log_data->>'$.status') STORED; ALTER TABLE logs ADD INDEX idx_status_v (status_v);
函数索引不是万能解药
MySQL 的函数索引只支持「确定性」表达式，而 JSON 函数在部分版本中被标记为非确定性（尤其是含数组下标或动态路径时），导致建索引失败：
-
log_data->>'$.items[0].id'可能报错ERROR 3905: Function is not allowed in generated columns or functional index -
JSON_EXTRACT(log_data, '$.meta.created_at')若返回NULL或类型不一致，函数索引会跳过该行，查不到结果 - 升级到 MySQL 8.0.29+ 后，部分限制放宽，但仍需显式声明
STORED，且字段长度要预留足够（如时间戳建议用VARCHAR(32)）
最易被忽略的一点：JSON 字段本身没设 NOT NULL，一旦某行 json_col 为 NULL，所有基于它的生成列值也为 NULL，对应索引条目失效——线上突然查不到数据，往往卡在这儿。
