mysql 8.0+ 中 json 字段需通过生成列（stored 更稳妥）提取确定性表达式（如 data->>'$.user_id'）并显式定义类型后建索引，查询必须直接引用该列名才能生效。
MySQL 8.0+ 中 JSON 字段不能直接建索引，必须用虚拟列
MySQL 不允许对 JSON 类型字段直接创建索引（会报错 JSON column '<col>' is not supported in generated columns or indexes），但支持对基于 JSON 提取的表达式创建「生成列」（virtual 或 stored），再在该列上建索引。关键前提是：表达式必须是「确定性」且「可索引」的，比如 JSON_EXTRACT() 或更推荐的 -> 和 ->> 操作符。
- 虚拟列（
VIRTUAL）不占用额外磁盘空间，但每次查询仍需实时计算 —— 对简单提取（如取顶层字段）性能影响极小 - 必须显式指定列类型（如
CHAR(32)、UNSIGNED INT），且长度/范围要覆盖实际数据，否则截断或转换失败 -
->>比->更常用：前者返回去引号字符串（适合索引），后者保留 JSON 引号（如"value"→ 索引效果差）
如何为 JSON 内的 user_id 字段添加高效索引
假设表 orders 有 data JSON 字段，其中存储 {"user_id": 123, "status": "paid"}，想按 user_id 快速查询。
ALTER TABLE orders ADD COLUMN user_id INT UNSIGNED AS (data->>'$.user_id') STORED, ADD INDEX idx_user_id (user_id);
注意：STORED 比 VIRTUAL 更稳妥 —— MySQL 8.0.13+ 对 VIRTUAL 列上的索引在某些优化器路径下可能失效；STORED 列值物理存储，索引行为更可预测。虽然多占一点空间，但换来的是稳定性和兼容性。
- 字段名
user_id不能和已有列重名，也不能用保留字（如order、group） -
data->>'$.user_id'中的$是 JSON 路径根节点，单引号防止 shell 或 SQL 解析干扰 - 如果
user_id可能为NULL，确保列定义允许 NULL（上面示例用了INT UNSIGNED，默认非空，需加NULL）
WHERE 条件中必须显式使用虚拟列，不能继续写 JSON 函数
建完索引后，查询必须直接引用新列名，否则索引不会生效。下面两种写法效果天壤之别：
✅ 走索引：
SELECT * FROM orders WHERE user_id = 123;
❌ 不走索引（即使逻辑等价）：
SELECT * FROM orders WHERE data->>'$.user_id' = '123';
- 第二条语句触发全表扫描：优化器无法将运行时 JSON 提取与虚拟列索引关联
- 类型隐式转换风险：若虚拟列是
INT，但查询传入字符串'123'，可能触发类型转换导致索引失效（应统一用123） - 路径错误不会报错，但返回空结果 —— 检查
EXPLAIN的key字段是否为idx_user_id
嵌套结构和数组元素的索引限制很现实
对 {"items": [{"id": 1}, {"id": 2}]} 这类结构，想索引所有 items[*].id，MySQL 原生不支持「JSON 数组展开索引」。常见折中方案只有两个：
- 用
JSON_CONTAINS()+ 全文索引（仅适用于搜索存在性，不支持范围查询） - 拆表：把
items提到独立关系表（如order_items），这是最可靠、可扩展的方式
试图用 JSON_EXTRACT(data, '$.items[0].id') 建索引只能覆盖第一个元素，业务稍一变化就失效。虚拟列不是万能胶，它只解决「确定路径 + 确定位置」的提取场景。
真正容易被忽略的是：虚拟列的表达式一旦上线，就不能随意修改其定义（比如从 ->> 改成 ->），否则会导致索引失效甚至数据不一致。上线前务必在测试环境用真实数据量验证 EXPLAIN 和查询响应时间。
