MySQL 8.0函数索引比5.7虚拟列“更好用”的唯一真实原因是CREATE INDEX直接支持函数表达式且优化器能自动匹配，无需改写SQL；其他所谓优势多为误解。
CREATE INDEX 语法直接支持函数表达式，不用手动建虚拟列——这是 8.0 函数索引比 5.7 虚拟列“更好用”的唯一真实原因。其他所谓“更好”，基本是误解或强行对比。
MySQL 5.7 的虚拟列根本不是函数索引
5.7 支持生成列（GENERATED COLUMN），但你不能对它建“函数索引”：
- ALTER TABLE t ADD COLUMN name_upper VARCHAR(255) GENERATED ALWAYS AS (UPPER(name)) STORED 是合法的
- CREATE INDEX idx_name_upper ON t(name_upper) 也是合法的，但这只是普通列索引
- 它解决不了 WHERE UPPER(name) = 'ABC' 这类查询——因为优化器根本不认识 UPPER(name) 和 name_upper 之间的语义关系
- 你必须把业务 SQL 改成 WHERE name_upper = 'ABC'，否则索引完全不生效
MySQL 8.0 的函数索引是语法 + 优化器协同生效
8.0.13+ 真正让 CREATE INDEX idx ON t((UPPER(name))) 可用，关键在两点：
- 解析器能认出双括号里的表达式，不再报 ERROR 1064
- 优化器能在 WHERE UPPER(name) = 'ABC' 中精确匹配该索引定义，命中底层自动生成的不可见虚拟列
常见错误现象：
- 升级后执行 EXPLAIN SELECT * FROM t WHERE UPPER(name) = 'ABC'，key 字段为空 → 很可能函数名大小写/空格不一致，比如索引建的是 (UPPER(name))，而查询写了 (upper(name))
- SHOW CREATE TABLE t 看不到显式虚拟列名，但 EXPLAIN FORMAT=JSON 里 key 显示的是类似 func_001 的名字，别误以为没生效
- 对 UPPER(name) LIKE 'ABC%' 期望走索引？大概率不会——B+ 树只支持左侧固定前缀的范围扫描，LIKE 模糊匹配仍受限
为什么不能直接说“8.0 更好用”？
函数索引不是万能加速器，它带来新约束：
- 函数必须确定性：NOW()、RAND()、UUID() 直接报 ERROR 3905
- 表达式必须字面完全一致：括号层级、空格、大小写差一点都不行
- STORED 是硬性要求，VIRTUAL 不支持建索引
- 索引长度仍受 innodb_large_prefix 限制，对超长字段做 UPPER() 可能建失败
真正容易被忽略的一点：函数索引的价值不在“省了一步建列”，而在让旧 SQL 不改就能受益——前提是，你愿意为那一行 CREATE INDEX 多做几次 EXPLAIN 验证和空格校对。
