mysql不支持直接对json字段建索引,必须通过generated column提取标量值并建索引,否则where json_col->>'$.field'必全表扫描;因json列不满足b+树索引要求,且create index idx on t(json_col->>'$.status')会报error 3152。

不能直接对 JSON 字段建索引,必须用 GENERATED COLUMN 提取值再建索引,否则查询永远全表扫描。
为什么 CREATE INDEX idx ON tbl(json_col->'$.field') 会失败或无效
MySQL 不支持函数索引(直到 8.0.13 才有限支持,且仅限确定性表达式 + 虚拟列方式)。直接在 CREATE INDEX 中写路径表达式会报错 ERROR 3152: JSON column cannot be used in key specification;即使语法通过(如建在 json_col 整体上),该索引也只用于 json_col IS NULL 或 JSON_VALID(json_col) 这类元信息判断,对 -> 或 ->> 查询完全无加速作用。
-
json_col->'$.field'返回 JSON 类型(带双引号),无法和字符串字面量直接等值比较 -
json_col->>'$.field'才返回去引号的标量值,但 MySQL 不允许在INDEX语句里直接用它 - 真正能建索引的,只能是显式定义的
STORED或VIRTUAL虚拟列
如何正确定义虚拟列:类型、STORED、NOT NULL 缺一不可
虚拟列必须匹配提取值的实际类型,且推荐用 STORED(物理存储)而非 VIRTUAL(查询时计算),避免优化器在某些路径下跳过索引。若字段可能为 NULL,需显式声明 NULL,否则 NOT NULL 约束会导致插入失败或结果不一致。
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 字符串路径(如
$.name)→ 用VARCHAR(N)+->>提取,例如:name_str VARCHAR(64) GENERATED ALWAYS AS (info->>'$.name') STORED - 整数路径(如
$.user_id)→ 用INT UNSIGNED或INT,并注意是否允许NULL:user_id INT GENERATED ALWAYS AS (info->>'$.user_id') STORED NULL - 布尔值 → 映射为
TINYINT(1),用JSON_EXTRACT()后转布尔逻辑,或直接->>+ 比较 - 务必用
->>而非->:前者输出alice,后者输出"alice",类型错配会导致索引命中失败
建索引后 WHERE 条件必须改写为虚拟列名
索引只对虚拟列本身生效,不会“自动重写”原始 JSON 查询。如果继续写 WHERE info->>'$.status' = 'active',EXPLAIN 仍显示 type: ALL(全表扫描)。
- ✅ 正确写法:
WHERE status = 'active'(假设虚拟列为status) - ✅ 支持
LIKE查询(如WHERE name_str LIKE 'John%'),但需确保虚拟列类型足够宽且索引可范围扫描 - ❌ 错误写法:
WHERE JSON_CONTAINS(info, '"active"', '$.status')或WHERE JSON_SEARCH(info, 'one', 'active', NULL, '$.status')—— 这两个函数完全不走索引 - 数组场景慎用:
info->'$[*].tag'是多值路径,MySQL 8.0.17+ 才支持CAST(... AS CHAR ARRAY)创建多值索引,普通 B+ 树索引不适用
STORED 比 VIRTUAL 更稳妥,但别忽略空间成本
STORED 列把提取值真实写入磁盘,索引行为稳定、兼容性好,尤其适合读远多于写的业务场景(如订单状态、用户标签)。而 VIRTUAL 列虽省空间,但在高并发或复杂查询计划中,MySQL 优化器可能无法可靠识别其确定性,导致索引被忽略——这不是 bug,是设计权衡。
- 一个
STORED虚拟列增加的存储≈该字段平均长度 × 行数,比存完整 JSON 小得多(索引只存提取值,非整个 JSON blob) - 若 JSON 字段本身已用
COMPRESSED行格式,STORED列额外开销通常可接受 - 线上变更前务必在从库或测试环境跑
EXPLAIN FORMAT=JSON,确认key和used_key_parts出现在预期列上










