MySQL不支持对自定义函数进行索引下推，无论是否声明DETERMINISTIC，均无法在索引匹配阶段预计算，必须逐行调用函数导致全表扫描；唯一可行方案是使用STORED虚拟列加索引。
MySQL对自定义函数不支持索引下推
MySQL优化器只内置识别一部分确定性函数（如 YEAR()、DATE()、UPPER()），而对用户通过 CREATE FUNCTION 定义的函数，无论是否标记为 DETERMINISTIC，均不会在索引匹配阶段做任何下推或预计算。查询执行时，MySQL必须逐行调用该函数，再比对结果——这直接绕过了索引的B+树结构。
自定义函数导致全表扫描的典型现象
假设你有表 orders，created_at 字段建了普通索引，又创建了如下函数：
DELIMITER $$
CREATE FUNCTION format_date(dt DATETIME) RETURNS DATE
DETERMINISTIC
BEGIN
RETURN DATE(dt);
END$$
DELIMITER ;
然后执行：
SELECT * FROM orders WHERE format_date(created_at) = '2026-10-15';
即使 EXPLAIN 显示 type=ALL 或 key=NULL，也说明没走索引。这不是配置或统计信息问题，而是引擎层根本无法将该函数“折叠”进索引查找逻辑。
- MySQL 8.0+ 的函数索引（如
ADD INDEX idx_f ((format_date(created_at)))）仅支持**内置函数**或**确定性表达式**，不支持自定义函数 -
DETERMINISTIC仅影响复制和查询缓存行为，不影响索引使用决策 - 哪怕函数体只有一行
RETURN DATE(dt)，MySQL仍视其为“黑盒”，拒绝索引下推
替代方案：用虚拟列 + 函数索引（仅限MySQL 8.0+）
如果你真需要基于函数结果加速查询，唯一可行路径是把计算结果物化为虚拟列，并在该列上建索引：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
ALTER TABLE orders ADD COLUMN created_date DATE AS (DATE(created_at)) STORED; CREATE INDEX idx_created_date ON orders (created_date);
之后查询改写为：
SELECT * FROM orders WHERE created_date = '2026-10-15';
-
STORED是关键：只有STORED列才能被索引；VIRTUAL列不能建索引（MySQL 8.0.23+ 允许但需显式指定INVISIBLE等额外条件，实际不推荐） - 注意字段类型要严格匹配函数返回值，比如
DATE(created_at)返回DATE，就不能用VARCHAR类型虚拟列去接 - 虚拟列本身不占额外存储（
STORED除外），但会增加 INSERT/UPDATE 开销
最容易被忽略的细节：函数索引括号必须成对
很多人尝试直接写：
CREATE INDEX idx_f ON orders (format_date(created_at)); -- ❌ 报错
正确写法必须用双层括号包裹表达式：
CREATE INDEX idx_f ON orders ((format_date(created_at))); -- ✅ 但依然无效——因为 format_date 是自定义函数
真正能生效的只能是内置函数表达式，例如：
CREATE INDEX idx_f ON orders ((DATE(created_at))); -- ✅ 可用
少一对括号、多一个空格、或用了自定义函数名，都会让语句失败或静默退化为普通索引——这种错误在批量建索引脚本里极难排查。
