JSON字段用->>或JSON_EXTRACT()在WHERE中必然不走索引，因B+树仅识别原始列值，无法匹配运行时解析结果；MySQL 8.0需用函数索引（如CREATE INDEX idx_price ON goods ((CAST(details->>'$.price' AS UNSIGNED)))）或STORED生成列来固化路径提取。
直接在 WHERE 条件里用 json_col->>'$.key' 查询，一定不走索引——这不是配置问题，是 MySQL 的 B+ 树索引根本无法识别运行时 JSON 解析表达式。想让查询快，必须把路径提取动作“固化”进索引结构里。
为什么 ->> 和 JSON_EXTRACT() 在 WHERE 里必然全表扫描
MySQL 的普通索引只认原始列值，不认函数输出。每次执行 details->>'$.price'，引擎都要对整条 JSON 做二进制解析、路径匹配、字符串剥离，这个过程无法复用索引节点。
- 即使你给
details字段加了INDEX(details)，MySQL 会静默忽略或报错：JSON 类型不支持直接建普通索引 -
EXPLAIN中看到type: ALL、rows等于表总行数，就是典型症状 - 数据量从 1 万涨到 100 万，查询耗时不是线性增长，而是指数级恶化（尤其嵌套深、数组多时）
MySQL 8.0 函数索引的正确写法与致命细节
函数索引是 8.0.13+ 才真正可用的方案，但语法和类型约束极严，错一个字符就失效。
- 外层双括号
(())是强制要求：CREATE INDEX idx_price ON goods ((CAST(details->>'$.price' AS UNSIGNED)));—— 少一层括号直接报ERROR 1064 - 类型必须显式且匹配：JSON 里存的是数字
"price": 2999，就得用UNSIGNED；存的是字符串"status": "paid"，就得用CHAR(20) - 查询语句中的表达式必须和索引定义**逐字一致**：
WHERE details->>'$.price' = 2999可以命中，但WHERE CAST(details->>'$.price' AS UNSIGNED) = 2999就不行 -
ON EMPTY和ON ERROR不影响索引本身，但漏写会导致某条记录 JSON 路径缺失时整个查询失败（不是返回 NULL）
什么时候该用 STORED 生成列，而不是函数索引
函数索引看着轻量，但遇到数组展开、类型容错、版本兼容等场景，STORED 列反而更稳。
- 要查 JSON 数组里的多个元素，比如
tags[*]，函数索引不支持（8.0.17 前），必须用：ALTER TABLE orders ADD COLUMN tag_list TEXT GENERATED ALWAYS AS (JSON_EXTRACT(extra, '$.tags')) STORED;再配全文索引或正则匹配 - 业务需要
ON ERROR DEFAULT 'unknown'这类行为，生成列可设默认值，函数索引做不到 - 表已有大量历史数据，且字段更新频繁，STORED 列的物理存储能避免优化器在不同版本间路径选择抖动（已知 8.0.13–8.0.16 存在函数索引偶发失效）
- 路径可能动态变化（如后期要查
$.items[2].name），生成列可随时新增，函数索引只能重建
嵌套数组查询别硬扛，用 JSON_TABLE() 下推解析
当你要从 {"orders": [{"items": [{"sku": "A001"}]}]} 这类结构里查 sku，JSON_EXTRACT() 每次都全量解析整棵树，性能随嵌套深度线性崩坏。
- 改用
JSON_TABLE()把解析下推到引擎层：SELECT o.id, jt.sku FROM orders o JOIN JSON_TABLE(o.extra, '$.orders[*]' COLUMNS (order_id INT PATH '$.id', NESTED PATH '$.items[*]' COLUMNS (sku VARCHAR(20) PATH '$.sku' ON EMPTY NULL ON ERROR NULL))) AS jt - 每级
NESTED PATH必须配独立COLUMNS，不能跨层引用（比如不能在 items 层直接写$.order_id） -
ON EMPTY和ON ERROR必填，否则某条记录字段类型不符（如"sku": 1001是数字），整行直接丢弃，不是填 NULL - 层级建议控制在 3 层内，超过后
JSON_TABLE()的内存开销和计划生成时间会明显上升
最易被忽略的一点：函数索引和生成列都解决不了「路径不确定」的问题。如果业务要求按 $.dynamic_{$key}.value 动态键名查询，这些方案全部失效——这时候该考虑拆表，或者引入 Elasticsearch 做二级索引。
