函数索引仅对WHERE或ORDER BY中字面量完全匹配建索引表达式的查询生效，如INDEX idx_upper_name ON users ((UPPER(name)))仅支持WHERE UPPER(name) = 'JOHN'，不支持WHERE name = 'john'或LOWER(name) = 'john'；必须使用确定性、无副作用函数（如UPPER、DATE），禁用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')：需确保 JSON 值结构一致，否则索引可能失效
以下函数建索引会直接报错：NOW()、CURDATE()、RAND()、UUID()、DATE_FORMAT()（非确定性，受会话变量影响）。
CREATE INDEX 语法必须严格套双括号
这是最常卡住的第一步。MySQL 对 DDL 语法极其敏感，错一个括号或大小写就失败：
- ✅ 正确：
CREATE INDEX idx_lower_email ON users ((LOWER(email))); - ❌ 错误：
CREATE INDEX idx_lower_email ON users (LOWER(email));（缺外层括号） - ❌ 错误：
CREATE INDEX idx_lower_email ON users (('LOWER(email)'));（引号包裹整个表达式） - ❌ 错误：
CREATE INDEX idx_lower_email ON users ((lower(email)));（函数名小写，严格模式下失败） - ❌ 错误：
CREATE INDEX idx_bad ON users ((email));（单列名套括号也不行，必须是真函数或真表达式）
另外，索引名不能和已有列名重复——比如表里已有 name 列，就不能再建 (name) 的函数索引。
为什么 EXPLAIN 显示 key 有值却还是 Using filesort
函数索引只参与数据查找，不自动承担排序责任。即使 key 字段显示命中了索引，只要 Extra 出现 Using filesort，说明排序没下推到索引层：
-
WHERE UPPER(name) = 'JOHN' ORDER BY UPPER(name)→ 不保证排序复用，仍可能Using filesort - 真正能避免排序的写法是
ORDER BY name配合普通索引，或ORDER BY UPPER(name)配合函数索引 + 确保优化器选择该路径 - COLLATE 子句干扰很隐蔽：比如建了
UPPER(name)索引，但查询写了UPPER(name COLLATE utf8mb4_0900_as_cs)，就会退化成全表扫描
验证是否真正命中，优先看 EXPLAIN FORMAT=TREE 输出中是否有 “Using secondary index” 并标出具体索引名；其次确认 possible_keys 和 key 一致，且 rows 远小于总行数。
函数索引本身不存冗余数据，但它不可被 SELECT * 返回，也不能在其他上下文中引用——它只服务于那个精确匹配的查询模式。一旦业务逻辑稍作调整（比如改用 INITCAP() 或加 COALESCE），就得重建索引，这点比 STORED 虚拟列更脆弱。
