当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 函数索引不生效时怎么检查表达式一致性

MySQL 函数索引不生效时怎么检查表达式一致性

来源：17golang原创 2026-09-07 22:50:05 0浏览收藏

MySQL 函数索引看起来已经建好，但查询仍然走全表扫描时，先别急着加更多索引。最常见的排查顺序是：把索引定义里的函数表达式与 WHERE 谓词逐字对照，再检查复合索引的前导列、查询需要的列和回表成本，最后用 SHOW INDEX、EXPLAIN 或 EXPLAIN ANALYZE确认优化器实际选择。

要点速览

DATE(created_at) 与 CAST(created_at AS DATE)不要默认当成同一个索引条件，函数、参数和转换方式先保持一致。
复合索引的列顺序决定能否利用前导列；索引包含查询所需列时，才可能减少回表。
EXPLAIN看到 key、访问类型和估算行数后，再结合统计信息判断，不要用 FORCE INDEX掩盖原因。

先确认索引里的表达式和查询谓词是不是同一件事

函数索引索引的是“表达式的值”，不是一个可以随意改写的函数名字。比如按天查询订单，可以把日期表达式放进索引：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  created_at DATETIME NOT NULL,
  status VARCHAR(20) NOT NULL,
  KEY idx_order_day ((DATE(created_at)), tenant_id, status)
);

对应的查询先保持同样的表达式形状：

SELECT id, tenant_id, status
FROM orders
WHERE DATE(created_at) = '2026-09-07'
  AND tenant_id = 17;

这里要核对四件事：函数是不是同一个、参数顺序是否相同、是否额外包了一层转换、常量类型是否和表达式结果相容。MySQL 官方文档用 SUBSTRING() 举例说明，索引定义和查询中的参数需要一致；所以把查询改成不同长度的截取、不同的转换链，不能只看“都在处理日期或字符串”就认为能命中。

MySQL 函数索引表达式一致性：orders.created_at、DATE(created_at)、索引定义和查询谓词的静态关系 — 图1：在索引定义边界与查询谓词边界之间对照函数、参数和常量，先判断表达式是否保持一致。

一个实用的对照表如下：

检查项	索引定义	查询侧要看什么
函数与参数	`DATE(created_at)`	不要随意替换为另一种转换写法
额外包装	表达式直接作为 key part	避免在外层再套不必要的函数
过滤条件	函数值参与索引	用等价且稳定的谓词表达目标日期

再看复合索引的列顺序和回表成本

表达式一致，只能说明“有机会使用”。上面的索引实际由函数列、tenant_id 和 status组成，查询能否有效缩小范围，还取决于索引列顺序。生产排查时把它拆成三个问题：

查询是否提供了前导 key part，还是只过滤了后面的列？
函数结果的选择性是否足够，命中行太多时全表扫描可能更便宜？
SELECT返回的列是否都在索引可获得的范围内，还是仍要回表读取整行？

以 idx_order_day ((DATE(created_at)), tenant_id, status)为例，日期与租户条件一起出现时，优化器更容易把它当成一个有边界的查找；如果只写租户条件，函数列在最前面就可能让这个索引不适合当前查询。反过来，如果业务最常按租户再按日期查，也可以评估 (tenant_id, (DATE(created_at)), status)的顺序，但要用真实查询集合比较，而不是凭列名排序。

覆盖索引也不要理解成“只要建了函数索引就不会回表”。InnoDB 二级索引会携带主键值；但查询如果还需要索引之外的列，仍然可能回到聚簇索引读取整行。图中把 PRIMARY(id)、SELECT 列、覆盖索引和回表放在同一访问关系里，便于定位这部分成本。

MySQL 复合函数索引的列顺序、PRIMARY(id)、覆盖索引与回表关系 — 图2：把复合索引键部件、SELECT 列和 PRIMARY(id) 放在同一张关系图中，判断查询是否能少一次回表。

用 SHOW INDEX 和 EXPLAIN 把猜测变成证据

先看索引当前到底长什么样，再看优化器对具体语句的判断：

-- 先核对索引名、顺序和基数等元数据
SHOW INDEX FROM orders;

-- 再看当前语句选择了哪个 key，以及预计扫描多少行
EXPLAIN FORMAT=JSON
SELECT id, tenant_id, status
FROM orders
WHERE DATE(created_at) = '2026-09-07'
  AND tenant_id = 17;

重点不是只看 possible_keys，而是看实际的 key、访问类型、估算行数以及是否出现覆盖索引相关信息。需要核对实际执行与估算偏差时，再在可接受的测试或灰度环境使用 EXPLAIN ANALYZE；它会执行语句，因此不要把它当成无副作用的计划预览。

如果索引定义和谓词都对，但计划仍不理想，可以先确认表统计信息是否过旧，再评估选择性与查询返回列。ANALYZE TABLE orders;会更新优化器使用的统计信息，但它不是“强制使用索引”的按钮；更新后仍应重新查看计划。