函数索引表达式匹配怎么配置或排查

MySQL 函数索引“建出来了却没被使用”，通常不是索引失效，而是要先分清两种情况：查询里的表达式没有匹配到索引定义，或者已经匹配，但优化器估算后认为另一条路径更便宜。配置时抓住三个点：MySQL 8.0.13 及以上用双括号定义函数索引；查询表达式尽量与索引定义保持一致；最后用 EXPLAIN 看 possible_keys 和 key，不要只凭感觉判断。

函数索引先怎么定义，双括号为什么不能省

以订单按天查询为例，原始字段是 created_at，业务条件却经常写成 DATE(created_at)。MySQL 8.0.13 及以上可以把这个表达式作为 functional key part：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  created_at DATETIME NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  -- 双括号表示这里索引的是表达式，而不是普通列名
  INDEX idx_created_day ((DATE(created_at)))
);

外层括号属于索引定义，内层括号包住函数表达式。若写成 INDEX idx_created_day (DATE(created_at))，解析器无法把它当作合法的函数索引定义。表达式也不能只是一个列名；如果只想索引 created_at，直接使用普通索引即可。

函数索引受到生成列规则约束，不能随意放入子查询、参数、变量、存储函数或不可用的函数。它的好处是不用把辅助列暴露给业务表，但索引本身仍然会占用空间，并增加写入时维护索引值的成本。

查询表达式怎么写才容易匹配

索引定义为 DATE(created_at) 时，下面的查询表达式方向一致：

SELECT id, amount
FROM orders
WHERE DATE(created_at) = '2026-09-13'; -- 让查询侧表达式与索引定义保持一致

这里的关键不是“出现了同一个函数名”，而是表达式结构和结果类型都要对得上。官方文档给出的边界是：生成列索引的匹配要求表达式一致且结果类型相同。因此，不要把索引定义写成 created_at + INTERVAL 1 DAY，查询却改成等价但结构不同的表达式，然后期待优化器一定替你做代数化简。

常见的错位包括交换运算顺序、把整数表达式和字符串比较、在查询侧额外包一层类型转换，以及索引定义和查询条件使用不同的 JSON 字符串处理方式。若业务代码会生成 SQL，建议把表达式片段集中成一个常量或查询构造器规则，避免多个团队各写一套“看起来等价”的表达式。

EXPLAIN 怎么区分不匹配和成本选择

排查时不要只看“有没有创建成功”，而要看查询计划。可以先执行：

EXPLAIN SELECT id, amount
FROM orders
WHERE DATE(created_at) = '2026-09-13'; -- 先观察候选索引和最终选中的索引

重点关注 possible_keys 与 key。如果两者都没有函数索引名，优先回到表达式结构、结果类型和版本能力上排查；如果 possible_keys 出现了索引名而 key 为空，说明优化器知道这条索引，但当前计划没有选它，接着看过滤条件、估算行数和统计信息。如果 key 已经是函数索引名，就说明匹配与选用都已经发生。

对生成列索引，SHOW WARNINGS 还能看到扩展 EXPLAIN 的重写信息。它适合确认优化器是否把查询表达式替换成了对应的生成列。注意，函数索引使用隐藏的虚拟生成列实现，所以你不应该在业务 SQL 中依赖一个不可见的列名；排查重点仍然是表达式和计划字段。

版本或函数受限时，什么时候改用生成列

如果目标实例低于 8.0.13，或者团队希望让计算结果成为明确的表字段，可以改用显式生成列再建立普通索引：

ALTER TABLE orders
  ADD COLUMN created_day DATE
    GENERATED ALWAYS AS (DATE(created_at)) STORED,
  ADD INDEX idx_created_day (created_day); -- 用显式生成列兼容旧式设计

这条路线的代价是表结构多了一个业务可见字段，写入和更新仍需要维护计算结果；优点是字段、类型和索引边界更直观，也便于部分工具展示。无论选哪种方式，都要把“查询是否包函数”与“是否有原始列索引”分开考虑：如果查询改写成时间范围条件，普通的 created_at 索引可能更合适；如果业务确实按日期表达式过滤，函数索引才有明确价值。

生产排查可以按这个顺序收口：先确认实例版本，再核对索引 DDL；然后复制同一表达式做 EXPLAIN；最后才考虑索引提示或统计信息。不要一看到全表扫描就立即加第二条近似索引，先证明原索引是“不匹配”还是“匹配但成本不划算”。

相关问题

函数索引为什么一定要写双括号？

双括号用于区分表达式键部分和普通列名。外层是索引键部分，内层是表达式本身，省略后 MySQL 可能按普通索引语法解析并报错。

表达式看起来等价，为什么仍然不走索引？

优化器匹配关注表达式一致性和结果类型，不保证对所有代数等价写法做归一化。先把查询侧改成与索引定义相同的结构，再用 EXPLAIN 观察。

possible_keys 有值但 key 为空怎么办？

这通常表示索引是候选项但没有被最终选中。继续检查估算行数、过滤条件和统计信息，不要把它直接判定为表达式匹配失败。