MySQL JSON 数组查询为什么不走索引：多值索引的适用边界

订单表把标签、区域编号或设备能力塞进 JSON 数组后，最常见的性能误判是：已经给 JSON 列建了索引，为什么查询仍然全表扫描？普通二级索引只对应一行一个键值，而一个 JSON 数组需要“一行多个键值”。MySQL 8.4 要用多值索引把数组元素拆成多个索引记录，并且查询谓词与类型也必须落在优化器支持的范围内。

普通索引为什么接不住 JSON 数组

假设 customers 表中的 custinfo JSON 保存 $.zipcode，值是一个 JSON 数组。普通索引无法把数组里的每个邮编都变成独立键。多值索引则用 CAST(... AS UNSIGNED ARRAY) 生成内部 虚拟列，再创建函数索引：

CREATE INDEX zips ON customers (
  (CAST(custinfo->'$.zipcode' AS UNSIGNED ARRAY))
);

结构上，数组元素 94507 会成为 多值索引 zips 中的一条记录，并继续指向 同一数据行。一行有三个数组元素，就可能有三个索引记录，但它们都关联同一个聚簇索引记录。

谓词和类型不匹配也会失去索引机会

官方手册列出的可优化入口是 MEMBER OF()、JSON_CONTAINS() 与 JSON_OVERLAPS()。例如索引声明为 UNSIGNED ARRAY，查询中的 查询常量类型 也要与它兼容：

SELECT id FROM customers
WHERE 94507 MEMBER OF(custinfo->'$.zipcode');

SELECT id FROM customers
WHERE JSON_CONTAINS(custinfo->'$.zipcode', CAST('[94507]' AS JSON));

仅仅写一个含义相近的 JSON 表达式，并不保证优化器能映射到 多值索引 zips。先看 EXPLAIN 的 possible_keys 与 key，再核对路径、强制转换类型和谓词形态，别把“存在索引”当成“必然选中索引”。

上线前要把写入成本和限制算进去

多值索引不是免费的读取加速器。数组越长，一次插入或更新需要维护的二级索引记录越多。它还明确 不能覆盖索引，不支持排序和范围扫描，也不能作为主键；复合索引中只允许一个多值键部分。创建多值索引不支持在线方式，会使用 ALGORITHM=COPY，大表必须预留变更窗口。

用 EXPLAIN 做最小验收

先在与生产相同的 MySQL 8.4 版本、字符集和数据分布上建立索引，执行真实谓词的 EXPLAIN。确认 key=zips 只是第一步，还要观察估算行数、回表量以及写入延迟。若数组主要用于范围、排序或高频更新，拆成关联表往往比继续扩张 JSON 数组更稳。

常见问题

给整个 JSON 列建普通索引可以吗？

不能直接解决数组成员查询。应针对具体 JSON 路径使用 CAST(... AS type ARRAY) 创建多值索引。

复合索引里能放两个 JSON 数组吗？

不行。官方限制是每个多值索引只能有一个多值键部分，其他键部分可以是普通单值列。

参考：MySQL 8.4 CREATE INDEX 与多值索引。