MySQL 生成列索引为什么没有命中表达式查询

MySQL 生成列索引没有命中表达式查询，通常不是“生成列不能索引”，而是查询里的表达式没有满足优化器的匹配条件。先看三件事：生成列定义是否确实建立了索引、WHERE 中的表达式是否与定义完全一致、比较值的数据类型是否一致。确认 EXPLAIN 中的 possible_keys 和 key 后，再判断是表达式不匹配，还是索引虽然可用但成本更高。

先确认生成列和索引确实存在

下面用订单金额举例。生成列 payable_amount 保存小计与运费之和，并在它上面建立索引。这里的 STORED 让计算结果随行保存，索引直接记录这个结果。

CREATE TABLE order_summary (
  id BIGINT PRIMARY KEY,
  subtotal DECIMAL(10,2) NOT NULL,
  shipping_fee DECIMAL(10,2) NOT NULL,
  -- 固定结果类型，避免查询时把金额隐式转换成字符串
  payable_amount DECIMAL(10,2)
    AS (subtotal + shipping_fee) STORED,
  -- 索引建立在生成列，而不是两个原始列的任意组合上
  KEY idx_payable_amount (payable_amount)
);

-- 先核对列定义与索引名称，避免只凭 ORM 配置判断
SHOW CREATE TABLE order_summary;

如果 SHOW CREATE TABLE 看不到生成列或 idx_payable_amount，先修复 DDL。还要确认索引没有被设置为 invisible；不可见索引不会被优化器正常选用。

让查询表达式和生成列定义完全一致

MySQL 文档给出的匹配规则很严格：查询表达式需要与生成列定义相同，并且结果类型也要相同。下面的写法与列定义一致，优化器才有机会把表达式替换为索引列。

-- 查询表达式与 AS (subtotal + shipping_fee) 保持相同顺序
EXPLAIN SELECT id, payable_amount
FROM order_summary
WHERE subtotal + shipping_fee > 1000.00;

-- 这个表达式虽然数学上等价，但不应假设一定能匹配
EXPLAIN SELECT id, payable_amount
FROM order_summary
WHERE shipping_fee + subtotal > 1000.00;

重点检查四类差异：操作数顺序、额外函数包裹、隐式类型转换和比较运算。比如生成列是整数表达式，查询却拿字符串字面量比较；或者定义是 f1 + 1，查询写成 1 + f1，都可能让 possible_keys 中没有这个索引。

JSON 提取要固定去引号和结果类型

JSON 是最容易出现“看起来一样、实际类型不同”的场景。若生成列从 JSON 中取字符串并用于索引，建议在列定义中明确去掉 JSON 字符串外层引号，并把最终类型写清楚。

CREATE TABLE user_profile (
  id BIGINT PRIMARY KEY,
  profile JSON NOT NULL,
  -- JSON_UNQUOTE 去掉 JSON 字符串的引号，再固定为可比较的字符类型
  city VARCHAR(64)
    AS (JSON_UNQUOTE(JSON_EXTRACT(profile, '$.city'))) STORED,
  KEY idx_city (city)
);

-- 查询侧保持相同的 JSON 表达式，比较值也按字符类型传入
EXPLAIN SELECT id
FROM user_profile
WHERE JSON_UNQUOTE(JSON_EXTRACT(profile, '$.city')) = 'Shanghai';

如果生成列定义没有 JSON_UNQUOTE，索引查找可能只对特定的 JSON 比较形式匹配。另一个边界是运算符：生成列索引的表达式替换主要覆盖 =、范围比较、BETWEEN 和 IN()；不要把任意函数条件都当成可索引条件。

用 EXPLAIN 区分匹配失败和成本选择

看到全表扫描时，先不要直接加更多索引。观察 possible_keys：如果没有 idx_payable_amount，优先回到表达式和类型检查；如果它出现在 possible_keys，但 key 为空，说明索引已被识别，只是成本模型可能认为扫描更合适。

-- 只读计划，不修改数据；重点看 possible_keys、key 和 type
EXPLAIN SELECT id
FROM order_summary
WHERE subtotal + shipping_fee > 1000.00;

-- 数据分布变化后，更新统计信息再重新观察计划
ANALYZE TABLE order_summary;

还要确认索引可见、谓词选择性和返回列是否符合预期。必要时可以在测试环境用索引提示做对照，但不要把提示当成表达式匹配的修复方案；它只能帮助判断优化器选型。

上线前检查清单

相关问题

为什么生成列有索引，查询直接写生成列名却仍然不快？

索引可用不等于一定低成本。先看过滤选择性、返回列和统计信息，再确认执行计划是否真的选择了该索引。

把表达式改成同义写法能提高命中率吗？

不要依赖数学等价。最稳妥的方式是让查询表达式按生成列定义原样书写，并固定比较参数类型。

可以只给原始字段分别加索引吗？

这不能替代表达式结果索引。原始字段索引是否有效取决于查询谓词能否单独利用它，不能自动复现生成列表达式的索引效果。