明明给字段建了索引可查询时加个简单的函数比如DATE(create_time)、UPPER(name)执行速度瞬间变慢EXPLAIN一看key字段显示NULL索引直接失效全表扫描找上门。比如这样一条SQLcreate_time明明有索引却依旧慢得离谱-- 索引失效全表扫描SELECT * FROM orders WHERE DATE(create_time) 2026-03-13;MySQL执行计划详解从看不懂到秒懂一线DBA的实战笔记其实问题很简单MySQL默认不会对“函数处理后的索引列”生效而解决这个问题的关键就是今天要和大家详细聊的MySQL函数索引。它不是什么高深的新特性却能帮助解决“函数操作导致索引失效”的痛点尤其在MySQL8.0之后用法更简洁、场景更广泛。一、什么是MySQL函数索引我们先明确一个核心前提普通索引是对“字段本身”建立索引比如给create_time建索引MySQL会直接对字段里的原始日期值排序、建立B树索引查询时能快速定位。但如果查询时对字段做了函数处理比如DATE(create_time)提取日期、LOWER(name)转小写MySQL就无法直接匹配索引的原始值。因为函数改变了字段的原始形态破坏了B树的有序性优化器只能放弃索引走全表扫描。而函数索引Functional Index就是针对“函数处理后的结果”建立的索引。简单来说就是MySQL提前把“字段函数”的计算结果算好存成隐藏的虚拟列再给这个虚拟列建索引查询时直接匹配计算结果不用再实时计算自然就能命中索引了。举个通俗的例子普通索引是“给苹果贴标签”函数索引是“把苹果切成块再给每块贴标签”查询时直接找切块后的标签省去了“现场切块”的时间。补充一个关键版本限制MySQL 8.0.13及以上版本才正式支持直接创建函数索引8.0之前的版本只能通过“虚拟列普通索引”的方式模拟实现操作更繁琐。二、函数索引的创建及使用函数索引的核心用法很简单下面结合3个高频场景带大家手把手实操。1. 基础语法MySQL 8.0.13创建函数索引的语法和普通索引类似唯一区别是函数表达式需要用双括号包裹避免和普通列索引混淆语法如下-- 通用语法CREATE [UNIQUE] INDEX 索引名 ON 表名 ((函数(字段名)));-- 示例给create_time的DATE()结果建索引CREATE INDEX idx_date_create_time ON orders ((DATE(create_time)));-- 示例给name的小写转换结果建唯一索引CREATE UNIQUE INDEX idx_lower_name ON users ((LOWER(name)));注意双括号是必须的如果少写一个括号MySQL会认为你是给普通列建索引直接报错或创建失败。2. 高频使用场景函数索引的核心价值就是解决“函数操作导致索引失效”的场景以下3个场景最常用。场景1日期字段的函数查询需求查询某一天的所有订单常用DATE(create_time) 日期此时普通索引失效创建函数索引即可解决。-- 1.无函数索引时全表扫描 mysql explain SELECT * FROM orders WHERE DATE(create_time) 2026-03-13;--------------------------------------------------------------------------------------------------------------| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |--------------------------------------------------------------------------------------------------------------| 1| SIMPLE | orders |NULL |ALL|NULL |NULL|NULL |NULL|298920| 100.00|Usingwhere |--------------------------------------------------------------------------------------------------------------1 row in set, 1 warning (0.00 sec)-- 2.创建函数索引针对DATE(create_time)mysql CREATE INDEX idx_date_create_time ON orders ((DATE(create_time)));Query OK, 0 rows affected (2.67 sec)Records: 0 Duplicates: 0 Warnings: 0 -- 3. 查询直接命中索引mysql explain SELECT * FROM orders WHERE DATE(create_time) 2026-03-13;------------------------------------------------------------------------------------------------------------------------------| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |------------------------------------------------------------------------------------------------------------------------------| 1 | SIMPLE | orders | NULL | ref | idx_date_create_time | idx_date_create_time | 4 | const | 1 | 100.00 | NULL |------------------------------------------------------------------------------------------------------------------------------1 row in set, 1 warning (0.01 sec)用EXPLAIN验证key字段会显示idx_date_create_timetype字段为ref说明索引生效避免了全表扫描。场景2字符串字段的大小写不敏感查询需求查询用户名时忽略大小写比如“ZhangSan”和“zhangsan”视为同一用户常用LOWER(name) zhangsan此时普通索引失效。-- 1. 创建函数索引针对LOWER(name)CREATE INDEX idx_lower_name ON users ((LOWER(name)));-- 2. 查询命中索引忽略大小写SELECT * FROM users WHERE LOWER(name) zhangsan;补充如果需要唯一约束比如不允许重复用户名忽略大小写可以创建唯一函数索引避免重复数据。场景3字符串截取查询需求查询手机号前3位为138的用户常用SUBSTRING(phone, 1, 3) 138普通索引失效创建函数索引即可。-- 1. 创建函数索引针对SUBSTRING(phone, 1, 3)CREATE INDEX idx_substr_phone ON users ((SUBSTRING(phone, 1, 3)));-- 2. 查询命中索引SELECT * FROM users WHERE SUBSTRING(phone, 1, 3) 138;3. 旧版本兼容方案MySQL 8.0之前如果你的MySQL版本低于8.0.13无法直接创建函数索引可以用“虚拟列普通索引”模拟步骤如下-- 1. 给表添加虚拟列存储函数计算结果ALTER TABLE orders ADD COLUMN date_create_time DATE GENERATED ALWAYS AS (DATE(create_time)) STORED;-- 2. 给虚拟列建普通索引CREATE INDEX idx_date_create_time ON orders (date_create_time);-- 3. 查询直接用虚拟列查询命中索引SELECT * FROM orders WHERE date_create_time 2026-03-13;关于虚拟列的介绍可以参考之前的文章一文搞懂MySQL虚拟列用法、选型与避坑注意虚拟列的表达式要和查询时的函数表达式完全一致否则无法命中索引STORED表示将虚拟列的值持久化存储查询更快但会占用少量存储空间。三、关键避坑这5个错误千万别犯函数索引好用但如果用错了不仅起不到优化效果还会浪费存储空间、拖慢写入速度。这5个坑一定要避开坑1函数不匹配索引白创建函数索引是“一对一”的——创建时用什么函数查询时就必须用什么函数否则无法命中索引。-- 错误示例创建的是LOWER(name)索引查询用UPPER(name)CREATE INDEX idx_lower_name ON users ((LOWER(name)));SELECT * FROM users WHERE UPPER(name) ZHANGSAN; -- 索引失效-- 正确示例函数完全匹配SELECT * FROM users WHERE LOWER(name) zhangsan; -- 命中索引坑2用了非确定性函数无法创建索引函数索引只支持确定性函数即相同的输入一定能得到相同的输出。像NOW()当前时间、RAND()随机数这种非确定性函数无法创建函数索引会直接报错。-- 错误示例用NOW()创建函数索引报错mysql CREATE INDEX idx_now ON orders ((NOW()));ERROR 3758 (HY000): Expression of functional index idx_now contains a disallowed function.坑3过度使用拖慢写入速度函数索引和普通索引一样需要占用存储空间而且每次插入、更新数据时MySQL都会自动重新计算函数结果更新索引因此索引越多写入速度越慢。建议只给“高频函数查询”创建函数索引低频查询没必要建避免得不偿失。可以改写SQL解决不要用函数索引解决。例如之前提到的案例里的date(create_time)2026-03-13的写法在create_time字段有索引的情况下改写为create_time2026-03-13 and create_time2026-03-14来解决更灵活。坑4忽略数据量小表用了反而更慢如果表的数据量很小比如不到1000行MySQL优化器会认为“走全表扫描”比“走索引”更快即使创建了函数索引也可能不会使用。建议小表无需创建函数索引只有数据量较大万级以上、函数查询频繁时再考虑使用。坑5混淆“函数索引”和“前缀索引”前缀索引是对“字段前N个字符”建索引比如name(10)适用于长字符串字段节省存储空间而函数索引是对“函数计算结果”建索引两者场景不同不能混淆。比如对bio字段长文本如果需要按首字母查询用函数索引如果只是按前10个字符查询用前缀索引更高效。四、总结最后用3句话总结函数索引的核心要点方便大家快速记忆、落地使用核心作用解决“索引列被函数操作后失效”的问题本质是对“函数计算结果”建索引提前缓存计算值适用场景日期函数查询、字符串大小写匹配、字符串截取等高频函数操作且数据量较大万级以上最佳实践少建、精准建创建时保证函数匹配避免非确定性函数同时权衡写入速度和查询速度其实MySQL索引优化的核心从来不是“建越多越好”而是“精准匹配场景”。函数索引看似简单但用好它能解决很多开发中的实际痛点尤其是在报表查询、数据分析等场景中能大幅提升查询效率。你平时开发中有没有遇到过“索引失效”的问题留言区聊聊你是怎么解决的关注我的微信公众号【数据库干货铺】后续分享更多数据库运维及优化干货避开各种开发坑