MySQL 函数索引怎样覆盖日期表达式查询

按天查询订单时，很多人会直接写 WHERE DATE(created_at) = '2026-10-17'。如果表上只有 created_at 的普通索引，优化器未必能把这个函数表达式直接转换成对原始列的索引范围；在 MySQL 8.0.13 及以上版本，可以把表达式本身做成函数索引。最小写法是：

-- 函数索引的键部分要用双层括号包住表达式
CREATE INDEX idx_order_day
    ON orders ((DATE(created_at)));

-- 查询中的表达式与索引定义保持一致
SELECT id, user_id, total_amount
FROM orders
WHERE DATE(created_at) = '2026-10-17';

本文只讨论表达式一致性和索引可用性，不把所有日期慢查询都归结为“加函数索引”。MySQL 官方文档地址：https://dev.mysql.com/doc/refman/8.4/en/

先分清：按天表达式和时间范围是两种查询模型

如果业务真正需要的是某个自然日，DATE(created_at) 表达的是“把每一行时间值投影成日期后再比较”。而普通索引直接排列的是 created_at 的原始值。查询条件包住列时，普通列索引不一定能像下面的范围条件一样直接形成连续范围：

-- 用左闭右开范围表达一个自然日，避免把结束时间写成 23:59:59
SELECT id, user_id, total_amount
FROM orders
WHERE created_at >= '2026-10-17 00:00:00'
  AND created_at 

范围条件通常是原始时间列索引的自然用法；函数索引适合那些确实以表达式作为查询契约、又希望保留 DATE(created_at) 语义的场景。两者不是简单的谁替代谁。

创建函数索引时，双层括号不能省

MySQL 的函数索引键部分写成 (expr)，而整个索引定义本身还要再包一层括号，所以日期表达式最终是 ((DATE(created_at)))。少一层括号，解析器会把它当成普通键部分的错误写法。

-- 建表示例：订单表保留原始时间，索引保存按天表达式的键值
CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    created_at DATETIME NOT NULL,
    total_amount DECIMAL(12, 2) NOT NULL,
    INDEX idx_created_at (created_at)
);

-- 函数索引表达式必须用双层括号
CREATE INDEX idx_order_day
    ON orders ((DATE(created_at)));

函数索引索引的是表达式结果，并不是额外暴露一个普通业务列。MySQL 文档说明，这类键部分通过隐藏的虚拟生成列实现；虚拟列本身不单独保存值，但索引仍然会占用索引空间。

查询写法要和索引表达式对齐

函数索引的可用性首先取决于表达式是否一致。索引定义是 DATE(created_at) 时，最直接的匹配条件就是同样的表达式：

-- 条件中的函数、列和参数保持与索引定义一致
SELECT COUNT(*) AS order_count
FROM orders
WHERE DATE(created_at) = '2026-10-17';

-- 组合条件仍然可以把日期表达式作为一个过滤项
SELECT id, user_id
FROM orders
WHERE DATE(created_at) = '2026-10-17'
  AND user_id = 10086;

不要把“逻辑上等价”误认为“优化器一定会把它们视为同一个函数键”。例如把索引定义改成 CAST(created_at AS DATE)，却仍然只期待 DATE(created_at) 自动命中，就会让排查变得模糊。稳定做法是先固定一种表达式，再让 DDL、SQL 模板和执行计划检查使用同一份定义。

如果查询可以改成时间范围，优先比较两种方案的实际计划：

-- 这个写法不依赖函数索引，而是使用原始 created_at 的范围边界
SELECT id, user_id
FROM orders
WHERE created_at >= '2026-10-17 00:00:00'
  AND created_at 

用 EXPLAIN 判断是否真的选中了函数索引

创建完成并不等于每次查询都必然使用它。先查看执行计划，再核对索引定义：

-- 先确认优化器为这个查询选择了哪个索引
EXPLAIN
SELECT id, user_id, total_amount
FROM orders
WHERE DATE(created_at) = '2026-10-17';

-- 再查看函数键对应的表达式
SHOW INDEX FROM orders;

在 EXPLAIN 结果中，重点看 possible_keys、key 和 rows：possible_keys 表示候选索引，key 表示本次计划实际选择的索引；如果 key 是 idx_order_day，才说明这次计划选中了它，rows 则是优化器估算需要检查的行数。

SHOW INDEX 的结果里，函数键的 Column_name 可能为空，而 Expression 会显示表达式。这样可以先确认“索引到底定义成了什么”，再解释为什么计划没有选中它。

版本和函数限制决定了迁移方案

函数键部分从 MySQL 8.0.13 开始支持。如果目标环境更老，不能直接照搬上面的语法，可以使用生成列再给生成列建普通索引：

-- 生成列方案把表达式显式命名，便于跨环境排查和引用
ALTER TABLE orders
    ADD COLUMN order_day DATE
        GENERATED ALWAYS AS (DATE(created_at)) VIRTUAL,
    ADD INDEX idx_order_day (order_day);

-- 查询时直接使用生成列，表达式关系由表结构维护
SELECT id, user_id
FROM orders
WHERE order_day = '2026-10-17';

生成列和函数索引都不是任意 SQL 片段的容器。函数索引继承生成列的限制，子查询、参数、变量、存储函数和可加载函数不能放进函数键表达式；函数键也不能直接作为主键或外键的一部分。涉及这类函数时，应先查目标版本文档，再决定是否把计算前移到写入阶段。

最后用一张表做选择

判断日期索引是否有效，可以按这个顺序收尾：确认服务版本支持函数键；核对 DDL 是否有双层括号；让 WHERE 表达式与索引定义一致；用 EXPLAIN 看 key；用 SHOW INDEX 看 Expression。如果业务允许范围条件，再把它和函数索引计划放在同一份数据分布上比较。

相关问题

为什么函数索引创建语句要写两层括号？

内层括号标出表达式键部分，外层括号属于索引键列表语法；两层合起来才能让 MySQL 把 DATE(created_at) 识别为函数键。

SHOW INDEX 看不到普通列名是不是索引坏了？

不一定。函数键的 Column_name 可能为空，应查看 Expression 是否显示了预期表达式。

时间范围查询和函数索引只能二选一吗？

不是。它们服务于不同查询写法，最终应以表达式契约、数据分布和执行计划决定是否同时保留，避免仅凭索引数量做结论。