能，但仅限于显式创建对应函数表达式的索引；MySQL 8.0 不自动推导，需双括号语法且表达式须确定性，虚拟列索引更易维护。
MySQL 8.0 函数索引能绕过 WHERE 中的表达式计算吗？
能，但仅限于你显式创建了对应函数表达式的索引。MySQL 不会自动为 WHERE name LIKE '%abc%' 或 WHERE YEAR(create_time) = 2023 这类带函数/运算的条件“推导”出可用索引——它只认字面匹配的索引定义。
也就是说，如果写 WHERE UPPER(name) = 'ABC'，只有当你建了 INDEX idx_upper_name ((UPPER(name)))，这个查询才可能走索引；否则照样全表扫描。
怎么创建合法的函数索引（带括号语法和限制）
MySQL 8.0 要求函数索引的表达式必须用双括号包裹，且表达式需满足「确定性」和「无副作用」。常见踩坑点：
-
CREATE INDEX idx_email_domain ON users ((SUBSTRING_INDEX(email, '@', -1)))✅ 合法，SUBSTRING_INDEX 是确定性函数 -
CREATE INDEX idx_rand ON t ((RAND()))❌ 报错，RAND() 非确定性 -
CREATE INDEX idx_json ON t ((json_extract(data, '$.status')))✅ 可行，但注意返回值类型是 JSON，比较时需类型一致（比如WHERE json_extract(data, '$.status') = '"active"'） - 不能包含用户变量、存储过程、子查询、临时表引用
WHERE 中用了函数，但没走函数索引？检查这几点
即使建了函数索引，查询仍可能不命中，典型原因：
- WHERE 条件里的表达式和索引定义**不完全一致**：比如索引是
((LOWER(name)))，但查询写了WHERE lower(name) = 'xxx'（小写）——没问题；但如果写成WHERE LOWER(TRIM(name)) = 'xxx'，就不匹配 - 隐式类型转换：索引表达式返回的是字符串，但 WHERE 里用了数字比较，如
WHERE (UPPER(name)) = 123，触发类型转换，索引失效 - 使用了不支持下推的函数：如
CONVERT_TZ()、NOW()等在索引定义中允许，但在 WHERE 中若混用非常量参数（如WHERE created_at > DATE_SUB(NOW(), INTERVAL 7 DAY)），即便有函数索引也无效 - EXPLAIN 显示
type: ALL或key: NULL，说明优化器根本没考虑该索引——可加FORCE INDEX验证是否真的可用
函数索引和虚拟列索引，选哪个更稳？
两者底层都依赖生成列机制，但虚拟列（GENERATED COLUMN）+ 普通索引更直观、调试友好：
- 函数索引：轻量，无需改表结构，适合临时或单一场景，但不可直接 SELECT，也不能设 DEFAULT 或 NOT NULL
- 虚拟列索引：显式定义列
email_domain VARCHAR(64) AS (SUBSTRING_INDEX(email, '@', -1)) STORED，然后INDEX(email_domain)—— 可查、可约束、可加注释，维护性更强 - 性能上无本质差异，但虚拟列在
SHOW CREATE TABLE中可见，排查时不容易遗漏；函数索引容易被忘记，尤其多人协作时
线上关键路径建议优先用虚拟列 + 索引，函数索引留给快速验证或无法改表结构的场景。
