函数索引仅对where或order by中字面量完全匹配建索引表达式的查询生效，如index idx_upper_name on users ((upper(name)))仅支持where upper(name) = 'john'，不支持where name = 'john'或lower(name) = 'john'；必须使用确定性、无副作用函数（如upper、date、substring_index），禁用now()、rand()等非确定函数；语法须严格：外层双括号、函数名大写、不可加引号；不可与现有列同名；相比stored虚拟列+普通索引，函数索引更轻量、不改表结构，但不可被select *返回，且复用性较弱。
函数索引不能“加速任意函数调用”，它只对 WHERE 或 ORDER BY 中字面量完全匹配建索引时所用表达式的查询生效。 比如你建了 INDEX idx_upper_name ON users ((UPPER(name)))，那只有 WHERE UPPER(name) = 'JOHN' 能走索引；WHERE name = 'john' 或 WHERE LOWER(name) = 'john' 一律不认。
哪些函数能用于 MySQL 8.0 函数索引
必须同时满足：确定性、无副作用、可比较、不含子查询或用户变量。常见可用函数包括：
-
UPPER()、LOWER()、TRIM()—— 字符串标准化场景（如邮箱/用户名忽略大小写查重） -
DATE()、YEAR()、MONTH()、DAY()—— 日期维度过滤，但注意：YEAR(created_at) = 2026可走索引，created_at >= '2026-01-01'不行 -
SUBSTRING_INDEX(email, '@', -1)—— 提取域名做索引，适合按邮箱后缀筛选用户 -
JSON_EXTRACT(profile, '$.status')—— 配合 STORED 虚拟列更稳，但函数索引本身也支持（需确保 JSON 值结构一致）
绝对不能用的有：NOW()、CURDATE()、RAND()、UUID()、DATE_FORMAT()（非确定性，建索引直接报错）。
建函数索引时最常踩的语法坑
MySQL 对 DDL 语法极其敏感，错一个括号或空格就失败：
- ✅ 正确：
CREATE INDEX idx_domain ON users ((SUBSTRING_INDEX(email, '@', -1)))（外层双括号 + 函数名大写） - ❌ 错误：
CREATE INDEX idx_domain ON users (SUBSTRING_INDEX(email, '@', -1))（缺最外层括号） - ❌ 错误：
CREATE INDEX idx_domain ON users (('SUBSTRING_INDEX(email, '@', -1)'))（引号包裹整个表达式） - ❌ 错误：
CREATE INDEX idx_domain ON users ((substring_index(email, '@', -1)))（函数名小写，严格模式下失败）
另外，函数索引名不能和已有列名重复，比如表里已有 name 列，就不能再建 (name) 的函数索引。
函数索引 vs STORED 虚拟列 + 普通索引，怎么选
两者都能实现类似效果，但行为差异明显：
- 函数索引不改表结构，适合临时优化单个查询，不想动 DDL 的场景
- STORED 虚拟列会新增一列，需要
ALTER权限，但可被SELECT *返回，且在多个查询条件（WHERE + GROUP BY + ORDER BY）中复用更稳定 - 如果表达式要用于 JOIN 条件或聚合，虚拟列更可控；如果只是简单等值过滤，函数索引更轻量
- 两者都不占额外磁盘空间（虚拟列是 STORED 才存，函数索引本身也不冗余存储）
真正容易被忽略的是：函数索引在 EXPLAIN 中是否命中，不能只看 possible_keys，必须确认 key 字段显示索引名，且 Extra 中没有 Using where 或 Using filesort —— 否则大概率是字符集、collation 或隐式类型转换导致表达式不完全匹配。
