函数索引必须使用双括号语法，仅MySQL 8.0.13+支持；表达式需确定、类型显式匹配，且WHERE中必须原样写出索引表达式才能生效。
CREATE INDEX 语法必须带双括号，否则索引建不成功；函数索引只在 MySQL 8.0.13+ 可用，低于该版本会报错。
函数索引的语法必须写对：两个括号不能少
MySQL 对函数索引的语法极其严格：CREATE INDEX idx_email ON t ((properties->>'$.request.email')) —— 外层那对括号 (()) 是必需的，不是笔误。少一个就会报 ERROR 1064 或 ERROR 3105。
常见错误写法：
-
CREATE INDEX idx_email ON t (properties->>'$.request.email')（单层括号，无效） -
CREATE INDEX idx_email ON t (CAST(properties->>'$.email' AS CHAR(100)))（漏掉外层括号）
正确写法必须是：
CREATE INDEX idx_email ON t ((properties->>'$.request.email'));
注意：即使你用了 CAST 或 JSON_UNQUOTE，也得套两层括号：((CAST(...)))。
表达式必须确定、类型要显式匹配
函数索引只接受「确定性表达式」——也就是每次输入相同 JSON，输出一定相同。像 NOW()、RAND()、子查询都不行，但 ->> 和 JSON_EXTRACT() 都满足。
类型不匹配会导致索引失效，哪怕只是隐式转换：
- 如果 JSON 中
user_id是数字，虚拟列或函数索引要用UNSIGNED INT，别用VARCHAR - 字符串路径提取后，建议用
CHAR(100)而非TEXT，因为TEXT不支持普通 B+ 树索引 - 日期字段如
$.created_at，应CAST(... AS DATETIME)，避免和字符串比较
验证方式很简单：EXPLAIN SELECT * FROM t WHERE properties->>'$.request.email' = 'a@b.com'; 如果 key 列为空、type 是 ALL，八成是类型或语法问题。
函数索引 vs STORED 生成列：选哪个？
函数索引看起来“不用改表结构”，但实际限制不少；STORED 生成列更可控，尤其在复杂场景下：
- 函数索引不支持多值数组展开（如
$.tags[*]），8.0.17 前必须靠STORED列 +ARRAY类型 - 函数索引无法定义
ON EMPTY/ON ERROR行为，出错直接中断查询；而生成列可设默认值或允许 NULL - 写入性能上，
STORED列值物理存储，更新时重算一次；函数索引虽不存值，但优化器路径更易受版本影响（尤其 8.0.13–8.0.16 有已知失效 case） - 如果你已在用
ALTER TABLE ... ADD COLUMN ... STORED，函数索引没额外收益；反之，新项目且路径固定、版本 ≥8.0.13，函数索引更轻量
一句话：想省事、路径简单、版本够新 → 用函数索引；要稳定、查数组、兼容旧版 → 用 STORED 生成列。
哪些 JSON 查询根本没法索引？
不是所有 ->> 场景都适合加函数索引，以下情况即使建了也白搭：
- 路径含动态拼接，比如
CONCAT('$.tag_', user_id)—— 优化器编译期无法确定路径 - 条件含通配符：
WHERE config->>'$.desc' LIKE '%error%'，B+ 树不支持前缀未知的模糊匹配 - 嵌套过深或使用
JSON_CONTAINS()这类函数，它们本身不可索引，也不能作为函数索引的表达式 - 单表不到 10 万行、QPS 很低，索引维护开销可能反超收益
真正值得投入的是那些高频、等值、路径稳定的查询，比如按 config->>'$.region_id' 或 config->>'$.theme' 筛选用户配置。
最常被忽略的一点：函数索引生效的前提，是你在 WHERE 子句里**必须原样写出索引表达式**；写成 config->>'$.region_id' = 123 才能命中，换成变量拼接或中间函数包装，索引就断连了。
