直接查 json 字段会全表扫描，因 b+ 树无法穿透 json 结构；需建虚拟列（json_unquote(json_extract())）并索引，查询时必须使用虚拟列名才能走索引。
为什么直接查 json_column->'$.field' 会全表扫描
MySQL 的 B+ 树索引无法穿透 JSON 字符串结构，-> 或 json_extract() 是运行时解析操作，优化器看不到底层字段值，自然没法走索引。哪怕你对 json_column 加了索引也没用——它索引的是整个 JSON 文本 blob，不是里面的 color 或 user_id。
创建虚拟列必须用 json_unquote(json_extract())
直接写 extras->'$.color' 会报错或生成带双引号的字符串（比如 "red"），导致后续等值查询匹配失败。正确写法是：
ALTER TABLE t_config
ADD COLUMN v_color VARCHAR(32)
GENERATED ALWAYS AS (json_unquote(json_extract(extras, _utf8mb4 '$.color'))) VIRTUAL;
-
json_extract()提取原始 JSON 值（可能带引号） -
json_unquote()去掉外层引号，得到干净字符串red -
_utf8mb4显式指定字符集，避免隐式转换警告 -
VIRTUAL节省空间，适合大多数场景；除非计算极重且查询极频繁，否则别用STORED
建索引前必须确保虚拟列允许 NULL 且类型匹配
如果 JSON 中该字段偶尔缺失，json_extract 返回 NULL，而虚拟列定义没声明 NULL，会导致插入失败。安全写法是显式加 NULL：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
ADD COLUMN v_request_id VARCHAR(32) GENERATED ALWAYS AS (json_unquote(json_extract(extra, _utf8mb4 '$.dist_request_id'))) VIRTUAL NULL;
- 类型长度要覆盖实际数据（如 UUID 用
VARCHAR(36)，手机号用VARCHAR(20)） - 不要用
TEXT或过长VARCHAR，否则无法建索引（InnoDB 对索引字段有长度限制） - 建完列立刻执行
CREATE INDEX idx_v_color ON t_config(v_color);，否则还是全表扫描
查询时必须查虚拟列，不能查原 JSON 表达式
索引只对虚拟列生效。下面两种写法效果天差地别：
-- ✅ 走索引 SELECT * FROM t_config WHERE v_color = 'red'; <p>-- ❌ 仍全表扫描（即使你刚建了虚拟列）<br> SELECT * FROM t_config WHERE extras->'$.color' = 'red';</p>
- 应用代码里所有条件都要切换到虚拟列名，不能留着旧写法
- 如果需要兼容新旧逻辑，可临时用视图包装，但视图不继承索引，性能无改善
- MySQL 8.0.17+ 支持多值索引查 JSON 数组，但 5.7 只能靠虚拟列 +
JSON_CONTAINS配合额外字段
虚拟列本身不存数据，但它的索引条目是实打实写进磁盘的——这意味着索引大小和主键一样真实，别以为“虚拟”就等于“轻量”。一个高频查询的虚拟列索引，可能比原表数据还占空间。
