MySQL JSON 字段怎么给列表筛选提速：生成列、索引与 NULL 边界

订单列表刚加上“渠道”和“会员等级”筛选时，把字段放进 JSON 看起来很省事：新增属性不用改表，接口也能直接返回整段配置。数据量上来后，JSON_EXTRACT(extra, '$.channel') 出现在每一条记录的筛选路径里，列表越翻越慢，慢查询里却只看到一个普通的 SELECT。

列表筛选卡住的地方，不在 JSON 返回而在每行计算

先假设有一张订单表，extra 保存渠道和会员等级：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  amount DECIMAL(12, 2) NOT NULL,
  extra JSON NOT NULL,
  created_at DATETIME NOT NULL
);

SELECT id, amount, created_at
FROM orders
WHERE JSON_UNQUOTE(JSON_EXTRACT(extra, '$.channel')) = 'wechat'
ORDER BY id DESC
LIMIT 20;

这条 SQL 在小表上很难看出问题。可筛选行数变多后，数据库需要为候选记录解析 JSON 路径，再判断是否等于 wechat。这不是“JSON 不能查询”，而是查询条件没有一个可以直接定位的索引入口。

这里先别急着给 extra 整列加索引。对于只按几个固定路径筛选的后台列表，把稳定路径抽成独立的生成列，通常更容易验证，也更容易给接口保留原来的 JSON 返回结构。

先把用户筛选状态映射成明确的 SQL 字段

列表页一般至少有三种状态：不筛选、筛选某个渠道、筛选“没有填写渠道”。后端不要把它们都拼成一个模糊的空值判断，可以先约定状态：

这样做的好处是，页面上的“全部”和“未填写”不会因为都被转换成空字符串而混在一起。接口层还应限制渠道值长度，避免把任意 JSON 路径或表达式交给 SQL 拼接。

用生成列固定 JSON 路径，再为高频条件建立索引

如果渠道值是短字符串，可以把它定义成字符类型的生成列。下面的表达式把 JSON 中的标量取出来，并让缺失路径自然落到 SQL NULL：

ALTER TABLE orders
  ADD COLUMN channel_key VARCHAR(32)
    GENERATED ALWAYS AS (
      JSON_UNQUOTE(JSON_EXTRACT(extra, '$.channel'))
    ) STORED,
  ADD INDEX idx_orders_channel_id (channel_key, id);

STORED 会在写入或更新时保存计算值，读取时不必重复计算；代价是增加列和索引的写入、存储成本。若表写入很少、查询表达式较复杂，可以评估 VIRTUAL 加二级索引，但不要把“少占列存储”理解成“没有索引成本”。

查询时直接使用生成列，意图更清晰：

SELECT id, amount, created_at
FROM orders
WHERE channel_key = 'wechat'
ORDER BY id DESC
LIMIT 20;

如果列表还按创建时间倒序，可以把排序列纳入索引，但列顺序要结合真实过滤比例、排序方式和回表成本测试。idx_orders_channel_id 只是本例的起点，不是所有订单表的固定答案。

类型、NULL 和空字符串要在结果页上分开

JSON 路径缺失、JSON 值为 null、生成列表达式得到 SQL NULL，以及值为 ''，在业务上可能对应不同的资料状态。先用几行数据把边界固定下来：

INSERT INTO orders (id, customer_id, amount, extra, created_at) VALUES
  (101, 7, 88.00, '{"channel":"wechat"}', NOW()),
  (102, 8, 36.00, '{"channel":null}', NOW()),
  (103, 9, 42.00, '{}', NOW()),
  (104, 10, 19.00, '{"channel":""}', NOW());

SELECT id, channel_key, channel_key IS NULL AS is_missing
FROM orders
WHERE id BETWEEN 101 AND 104
ORDER BY id;

通常可以把 channel_key IS NULL 作为“未填写”入口，把空字符串当作脏数据单独统计。若接口希望把 JSON null 和缺失键区分开，就不要只用一个字符串生成列，应增加一个表示路径存在性的标记列，并在数据写入时统一规则。

性能检查要同时看查询和写入预算

上线前至少做一组对照：原始 JSON 表达式、生成列但无索引、生成列加索引。每组使用相同数据量、相同过滤比例和相同排序条件，记录读取行数、响应时间、写入耗时和索引大小。

EXPLAIN ANALYZE
SELECT id, amount, created_at
FROM orders
WHERE channel_key = 'wechat'
ORDER BY id DESC
LIMIT 20;

重点观察实际读取行数是否下降、是否仍然大范围回表，以及排序是否成为新的瓶颈。写入侧则抽样执行订单创建和更新，确认生成列表达式不会因为类型截断或异常 JSON 使 DDL、INSERT 或 UPDATE 失败。

如果筛选值的区分度很低，比如九成订单都是同一个渠道，索引未必带来同等比例的收益；这时应把过滤、排序和返回列一起看，别只因为“有 key”就直接上线。

常见问题

生成列一定要用 STORED 吗？

不一定。STORED 更直观，读取时直接使用保存值，但会增加写入和磁盘成本；VIRTUAL 也可以建立二级索引，适合希望减少列存储、同时愿意复测写入路径的场景。

为什么查不到 channel_key IS NULL 的记录？

先确认 JSON 路径是否真的缺失或为 null，再检查生成列表达式的返回类型。空字符串不是 SQL NULL，不能用同一个条件替代。

直接给 JSON 列建索引不行吗？

JSON 列的索引方式受表达式、路径和版本能力影响。固定路径的生成列更容易和接口字段、EXPLAIN 结果一一对应，适合高频且稳定的筛选条件。

生成列索引上线后还要做什么？

持续观察慢查询、写入耗时、索引空间和筛选命中比例。数据分布变化后重新核对执行计划，必要时先撤销新索引或恢复旧查询路径。

小结

JSON 适合承载变化快、读取整段的扩展属性；当某个路径变成列表页的高频筛选条件，就应该把它当成一个需要命名、定类型、可索引的查询字段。生成列只是起点，真正稳妥的改造还包括筛选状态约定、NULL 边界测试、读写预算对照和上线后的执行计划复查。