MySQL 8.4 函数索引实战：字段一包函数，索引为什么就不走了

先说结论：字段被函数包住后，普通索引经常帮不上忙

很多慢查询不是没有索引，而是 SQL 写法让索引没法直接用。最常见的就是把列包进函数里：DATE(created_at)、LOWER(email)、RIGHT(phone,4)、JSON_EXTRACT()。优化器看的是表达式，不是你脑子里“这个表达式来自某个有索引的列”。

MySQL 8.x 可以用函数索引，也可以用生成列加索引来承接固定表达式。但我的习惯是：能改写 SQL 的，先改写；确实改不了、表达式稳定、收益明确，再上函数索引。

业务场景：按天查订单，明明有索引却全表扫

订单表有一个普通时间索引：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  created_at DATETIME NOT NULL,
  status TINYINT NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  KEY idx_created_at (created_at)
) ENGINE=InnoDB;

开发为了按天查询，写了这样一条 SQL：

SELECT id, amount
FROM orders
WHERE DATE(created_at) = '2026-06-04'
  AND status = 1
ORDER BY id DESC
LIMIT 100;

这条 SQL 读起来很自然，但 DATE(created_at) 让 MySQL 必须先计算表达式，再比较日期。普通的 idx_created_at 是按原始 DATETIME 值排序的，不等于天然能回答 DATE(created_at)。

第一优先级：把函数条件改成范围条件

按天查询其实可以写成半开区间：

SELECT id, amount
FROM orders
WHERE created_at >= '2026-06-04 00:00:00'
  AND created_at 

这个写法能直接利用 created_at 的有序性，通常比函数索引更简单、更稳。上线前用 EXPLAIN 看 key、type、rows，确认扫描范围明显收窄。

什么时候考虑函数索引

如果业务查询就是固定表达式，并且很难改，比如手机号后四位查询：

SELECT id, phone
FROM users
WHERE RIGHT(phone, 4) = '8899';

这时候可以评估函数索引：

CREATE INDEX idx_users_phone_last4
ON users ((RIGHT(phone, 4)));

或者对更复杂、需要复用的表达式使用生成列：

ALTER TABLE users
  ADD COLUMN phone_last4 CHAR(4)
    GENERATED ALWAYS AS (RIGHT(phone, 4)) STORED,
  ADD INDEX idx_phone_last4 (phone_last4);

函数索引写起来更直接；生成列更显式，也方便查询和排查。选择哪个，要看团队维护习惯、MySQL 版本、DDL 风险和表达式复用范围。

踩坑原因：表达式不一致就可能匹配不上

函数索引最容易踩的坑是“看起来一样，实际上表达式不一样”。比如索引建的是 LOWER(email)，查询里写成 LCASE(email)，或者表达式里多了 CAST、不同 collation、不同 JSON path。优化器未必会把它们当成同一个东西。

所以我会要求把函数索引对应的 SQL 写法固定下来，最好封进 DAO 或查询模板里，不要让各个业务随手拼表达式。

诊断：EXPLAIN 之外还要看索引定义

上线前至少做三件事：

SHOW INDEX FROM users;

EXPLAIN
SELECT id, phone
FROM users
WHERE RIGHT(phone, 4) = '8899';

ANALYZE TABLE users;

SHOW INDEX 看索引是否存在，EXPLAIN 看查询是否命中，ANALYZE TABLE 在变更后帮助统计信息更新。别只看建索引成功，建成功不代表查询一定会走。

上线风险：函数索引也要维护成本

函数索引不是免费的。每次写入、更新相关列，MySQL 都要维护表达式对应的索引项。对于写多读少的表，函数索引可能把读查询救快了，却把写入 P99 拉高。

我的做法是先从慢日志里确认查询频率和耗时，再在灰度环境做写入压测。函数索引适合高频、稳定、选择性不错的表达式，不适合为了少数后台查询给核心写表加额外负担。

个人经验：函数索引要配合 SQL 规范一起上线

函数索引最怕只由 DBA 建好，业务 SQL 继续各写各的。你建了 DATE(created_at)，有人写 created_at + INTERVAL 0 SECOND，有人写 CAST(created_at AS DATE)，最后还是乱。

我会在变更单里写清楚：索引表达式、允许的 SQL 模板、验证 EXPLAIN、回滚方式和慢日志观察窗口。这样函数索引才是工程方案，不是临时补丁。

总结

MySQL 8.x 的函数索引和生成列索引能解决“固定表达式查询无法用普通索引”的问题，但不要把它当第一选择。日期查询先改范围条件，大小写搜索先确认 collation，JSON 提取先确认数据模型。只有当表达式稳定、收益明确、写入成本可接受时，再用函数索引把访问路径固定下来。