MySQL 8.0函数索引直接索引表达式结果，解决WHERE中DATE()、LOWER()、SUBSTRING()等函数导致全表扫描的痛点，需双括号语法且查询条件必须字面一致，底层基于虚拟列实现。
MySQL 8.0 的函数索引不是“锦上添花”，而是解决一类长期被硬编码绕过的查询痛点——当你必须在 WHERE 条件里对字段做计算或转换时，传统索引完全失效，只能全表扫描。
函数索引真正解决的典型场景
这些查询在 MySQL 5.7 或更早版本中根本无法走索引：
-
SELECT * FROM orders WHERE DATE(created_at) = '2026-05-06'—— 时间字段带函数，索引失效 -
SELECT * FROM users WHERE LOWER(email) = 'ADMIN@EXAMPLE.COM'—— 忽略大小写匹配，email上的普通索引不命中 -
SELECT * FROM logs WHERE SUBSTRING(message, 1, 4) = 'ERROR'—— 截取前缀判断，前缀索引又不够灵活 -
SELECT * FROM products WHERE price * (1 + tax_rate) > 100—— 表达式计算，无对应列可建索引
过去只能靠加冗余字段（如 created_date、email_lower）+ 触发器/应用层同步维护，成本高、易出错、难收敛。函数索引让数据库直接索引“结果”，而不是“原始值”。
创建函数索引必须加双括号，否则语法报错
这是最容易卡住的第一步。MySQL 要求函数表达式必须显式用括号包裹，和普通列名严格区分开：
CREATE INDEX idx_lower_email ON users ((LOWER(email))); CREATE INDEX idx_date_created ON orders ((DATE(created_at))); CREATE INDEX idx_price_with_tax ON products (((price * (1 + tax_rate))));
以下写法全部非法：
-
CREATE INDEX idx_bad ON users (LOWER(email));—— 缺少外层括号，报错ERROR 1064 -
CREATE INDEX idx_bad2 ON users ((email));—— 单独列名套括号也不行，必须是“真函数”或“真表达式” -
CREATE INDEX idx_bad3 ON users (SUBSTRING(name, 1, 10));—— 同样缺括号，且未声明长度，会提示Function is not allowed in index
注意：SUBSTRING()、CAST() 等函数虽可用，但不能带列前缀（如 name(10)），必须写成完整表达式形式。
函数索引能用的前提：查询条件必须字面一致
优化器不会做表达式等价推导。哪怕只是多一个空格、换一种写法，索引就失效：
- 建了
((LOWER(email)))，但查询写WHERE email = LOWER('A@B.C')→ 不走索引 - 建了
((DATE(created_at)))，但查询写WHERE created_at >= '2026-05-06' AND created_at → 走索引（因为没用函数）；而写 <code>WHERE DATE(created_at) = '2026-05-06'→ 才走函数索引 - 建了
((price * 1.1))，但查询写WHERE price * 1.10 > 100→ 不走；必须严格匹配price * 1.1
这意味着你得把应用层 SQL 和索引定义对齐。上线前务必用 EXPLAIN 验证，别只看语义对不对。
函数索引背后是虚拟列，有隐性成本
MySQL 内部是通过隐藏的虚拟计算列实现函数索引的，这带来几个实际约束：
- 每个函数索引会占用一个“列槽位”，计入表的总列数限制（InnoDB 最多 1017 列）
- 仅支持能用于生成列（generated column）的函数，比如
ABS()、UPPER()、JSON_EXTRACT()可以，但NOW()、RAND()、子查询、用户自定义函数一律禁止 - 不支持
FULLTEXT或SPATIAL类型的函数索引 - 主键不能包含函数列，
UNIQUE索引可以，但要注意 NULL 处理逻辑（函数结果为 NULL 也会参与唯一性校验）
最常被忽略的一点：函数索引的统计信息更新不如普通列及时，大表首次创建后建议手动执行 ANALYZE TABLE tbl_name，否则优化器可能误判选择性，放弃使用该索引。
