mysql 8.0 中 json 列需通过函数索引或生成列间接建索引，单值提取须用 cast(... as char)、数组提取须用 cast(... as ... array)，且查询必须严格匹配索引表达式才能生效。
MySQL 8.0 中不能直接对 JSON 列建索引，必须通过函数索引或生成列间接实现
JSON 类型本身不支持直接创建 B+ 树索引。MySQL 的索引引擎（InnoDB）无法解析 JSON 文档结构，所以像 courses->'$.course_id' 这样的表达式，如果不落地为可索引的列，查询时只能全表扫描。8.0 引入的「函数索引」（Functional Index）正是为解决这个问题而生——它允许你把 JSON 提取逻辑固化进索引定义里，无需显式添加生成列。
关键点在于：CAST(... AS ... ARRAY) 是创建多值索引的必要语法，而普通单值提取（如 courses->'$.course_id'）需配合 CAST(... AS CHAR) 或其他标量类型才能建函数索引。
给 JSON 对象字段建索引：用 CAST(... AS CHAR) + 函数索引
适用于提取单个标量值的场景，比如 address->'$.city'、user->'$.email'。
错误写法（会报错）：
ALTER TABLE student ADD INDEX idx_city ((address->'$.city'));
MySQL 会提示 ERROR 3105 (HY000): Expression of generated column '...' cannot be used as index column，因为未显式指定类型转换。
正确写法（推荐虚拟列 + 索引，或直接函数索引）：
- 方式一（显式虚拟列 + 索引，兼容 5.7/8.0）：
ALTER TABLE student ADD COLUMN city VARCHAR(100) GENERATED ALWAYS AS (address->>'$.city') STORED, ADD INDEX idx_city (city);
- 方式二（8.0+ 函数索引，更轻量）：
ALTER TABLE student ADD INDEX idx_city ((CAST(address->'$.city' AS CHAR(100))));
注意：-> 返回的是带引号的 JSON 字符串（如 "北京"），->> 才是去引号的标量值（北京）。函数索引中建议统一用 -> + CAST，避免隐式转换歧义。
给 JSON 数组字段建多值索引：必须用 CAST(... AS ... ARRAY)
当你要查 courses 这种数组字段里任意元素的 course_id，比如「学生是否修过 CS101」，就必须用多值索引。
错误写法（无法命中索引）：
SELECT * FROM student WHERE JSON_CONTAINS(courses, '"CS101"', '$[*].course_id');
正确写法（唯一可靠方式）：
ALTER TABLE student ADD INDEX idx_course_id ((CAST(courses->'$[*].course_id' AS CHAR(50) ARRAY)));\n
说明：
-
$[*].course_id表示遍历数组中每个对象的course_id字段 -
CAST(... AS CHAR(50) ARRAY)告诉 MySQL 把提取出的所有course_id值转成一个 SQL 字符串数组，并为每个值单独建立索引项 - 后续查询必须用
JSON_CONTAINS(...)或MEMBER OF()才能走这个索引，不能用=或IN
函数索引的性能与陷阱：写入开销、长度限制、查询写法强绑定
函数索引不是“零成本加速”。它在 INSERT/UPDATE 时要实时计算表达式并写入索引页，比普通索引多一次 JSON 解析和 CAST 转换。
常见坑点：
-
key_len显示异常大（比如 203），是因为 MySQL 按最大可能长度预分配空间；实际存储取决于数据，但会影响缓冲池效率 - 索引键长度受
innodb_large_prefix和行格式影响：DYNAMIC/COMPRESSED 表最多支持 3072 字节，CHAR(50) ARRAY 在极端情况下可能超限 - 查询必须严格匹配索引定义里的表达式，比如建了
(CAST(courses->'$[*].course_id' AS CHAR(50) ARRAY))，就不能用courses->>'$[0].course_id'查找——后者不会走索引 - 虚拟列 + 索引 vs 直接函数索引：前者便于调试（可
SELECT虚拟列看值），后者省一个列定义；但两者底层都是物化到索引中的值，性能几乎一致
最易被忽略的一点：函数索引只在 WHERE 条件中以完全相同形式出现时才生效。哪怕多一个空格、换一种 JSON 路径写法（$[0] vs $[*]），优化器都会放弃使用。实操前务必用 EXPLAIN 验证 key 字段是否命中目标索引。
