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 文本里多一个缩进空格，就可能匹配失败。
iWebShop是一款基于PHP语言及MYSQL数据库开发的B2B2C多用户开源免费的商城系统，系统支持自营和多商家入驻、集成微信商城、手机商城、移动端APP商城、三级分销、视频电商直播、微信小程序等于一体，它可以承载大数据量且性能优良，还可以跨平台，界面美观功能丰富是电商建站首选源码。iWebShop开源商城系统 v5.14 更新日志：新增商品编辑页面规格图片上传优化商品详情页面规格图片与主图切
真正能提速的替代方案
核心原则：把 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，对应索引条目失效——线上突然查不到数据，往往卡在这儿。
