MySQL 生成列索引为什么比直接查 JSON 更稳定

把订单属性、设备标签或用户扩展字段放进 MySQL 的 JSON 列很灵活，但经常查询的路径如果每次都现场执行 JSON_EXTRACT()，类型、字符串引号和执行计划都容易变得难以判断。更稳妥的做法是：把固定 JSON 路径抽成生成列，明确它的 SQL 类型，再给生成列建立普通索引。

生成列索引稳定的核心，不是“JSON 一定更慢”，而是把半结构化路径转换成类型明确的标量键。字符串用 JSON_UNQUOTE() 去掉 JSON 引号，数值用合适的类型转换，最后用 EXPLAIN 看优化器是否真正考虑了这个索引。

直接查 JSON 时，真正不稳定的是什么

假设表里有一列 attrs JSON，其中保存 {"sku":"A100","stock":12}。直接写 WHERE JSON_EXTRACT(attrs, '$.sku') = 'A100' 可以得到结果，但这个表达式仍然要在查询条件中解析 JSON 路径；而且 JSON_EXTRACT() 对字符串返回的是 JSON 字符串值，显示时通常带引号。

数字和字符串也不能混着设计。库存适合变成整数，SKU 适合变成字符列；如果把两者都保留成模糊的 JSON 结果，比较规则、隐式转换和索引匹配都会变得不直观。这里的“稳定”首先指数据类型和查询边界稳定，不代表所有数据量下都必然更快。

用生成列把 JSON 路径固定成可索引类型

把经常出现在过滤条件中的路径单独定义出来，生成列可以选择 STORED 或保持默认的虚拟生成列。下面用存储型生成列演示，重点是表达式和 SQL 类型，而不是宣称某一种生成列在所有场景都更快。

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    attrs JSON NOT NULL,
    -- 把稳定的 SKU 路径转换成普通字符值
    sku VARCHAR(64) GENERATED ALWAYS AS (
        JSON_UNQUOTE(JSON_EXTRACT(attrs, '$.sku'))
    ) STORED,
    -- 把库存路径固定成无符号整数
    stock INT UNSIGNED GENERATED ALWAYS AS (
        CAST(JSON_UNQUOTE(JSON_EXTRACT(attrs, '$.stock')) AS UNSIGNED)
    ) STORED,
    -- 索引服务于经常过滤的标量路径
    KEY idx_orders_sku_stock (sku, stock)
);

这样做以后，查询可以直接使用 sku 和 stock，读者能从表结构看出字段含义，也能让索引按照字符或整数的规则工作。生成列会随着基列插入或更新而重新计算，因此要把它当作数据模型的一部分：路径改名、值类型改变或历史数据不完整，都需要配套迁移和回归。

字符串引号和表达式匹配为什么会影响命中

MySQL 文档特别提醒了字符串路径的一个坑：如果生成列直接写成 JSON_EXTRACT(attrs, '$.sku')，生成结果仍带 JSON 字符串语义。定义中加上 JSON_UNQUOTE() 后，普通字符比较更容易和索引列保持一致。

表达式也要尽量固定。生成列定义使用了 JSON_UNQUOTE(JSON_EXTRACT(attrs, '$.sku'))，查询就可以写成 WHERE sku = 'A100'；如果必须直接写 JSON 表达式，路径、函数和类型转换都应与生成列保持兼容。只换成另一个等价但结构不同的表达式，不应想当然地认为优化器一定能匹配。

另外，路径不存在时抽取结果可能是 SQL NULL。如果业务要求“没有库存就按零处理”，应在数据模型或查询条件中明确写出这个规则，而不是靠索引把 NULL、JSON null 和数字 0 混为一谈。

用 EXPLAIN 判断索引是否真的被考虑

建表或改表完成后，先看查询计划，不要只看 SHOW INDEX 里是否出现了索引名称。常用检查可以从直接引用生成列开始：

EXPLAIN SELECT id, attrs
FROM orders
WHERE sku = 'A100' AND stock > 0;

-- 关注 possible_keys 是否包含 idx_orders_sku_stock，
-- 再看 key 是否实际选择了它；两者都为空时先检查条件和统计信息
SHOW WARNINGS;

possible_keys 表示候选索引，key 表示这次计划选中的索引。即使 key 为空，也不一定说明定义错误：选择性不足、返回行太多、统计信息或其他索引成本更低，都可能让全表扫描更合理。反过来，看到索引名也不能替代真实业务数据上的检查。

常见问题

生成列索引是不是一定比直接查 JSON 快？

不是。它的主要价值是把固定路径和返回类型变得可见、可索引、可检查；是否更快还要看选择性、数据分布和执行计划。

为什么字符串生成列要写 JSON_UNQUOTE？

因为 JSON_EXTRACT 返回字符串时带 JSON 引号语义，JSON_UNQUOTE 可以把它转换为普通字符值，减少索引比较时的表达式不一致。

JSON 数组也适合用普通生成列吗？

如果只取一个稳定标量可以；如果要检索数组中的多个成员，应评估 MySQL 的多值索引或拆分关系表，不能把数组整体当成一个普通等值键。

实际落地时，先挑一个查询频率高、路径长期稳定的标量字段，给它明确类型，再用代表性数据执行 EXPLAIN。等结构和计划都确认后，再决定是否扩展到联合索引或更多 JSON 路径。