MySQL 5.7 完全不支持函数索引，语法解析即报错；8.0.13+ 才支持，本质是自动创建虚拟生成列并建普通索引，仅对等值及明确范围查询有效，LIKE 模糊匹配基本无效，需用 FORMAT=JSON 验证真实生效。
MySQL 5.7 完全不支持函数索引，任何尝试创建的语法都会在解析阶段直接报错；升级到 MySQL 8.0.13+ 后，函数索引才真正可用，但它的行为和限制远不止“写个函数就能加速查询”这么简单。
MySQL 5.7 执行 CREATE INDEX ON t((UPPER(name))) 必然失败
这不是配置没开、权限不够或 SQL 写错了，而是内核根本不认识这种语法。错误信息一定是：ERROR 1064 (42000): You have an error in your SQL syntax。连 SQL 解析器都过不去，更谈不上优化器识别或执行计划匹配。
- 别指望用生成列“绕过去”：5.7 虽支持生成列，但
INDEX ON (generated_col)是普通索引，不是函数索引——它不解决WHERE UPPER(name) = 'ABC'的索引失效问题 - 实际替代方案只有两个：建冗余字段（如
name_upper VARCHAR(64)）并对其建普通索引；或业务层统一存大写值，避免运行时计算 - 如果已有大量
UPPER()查询且无法改 SQL，5.7 下只能接受全表扫描或考虑应用层缓存
MySQL 8.0 函数索引本质是「虚拟生成列 + 普通索引」
你写的 CREATE INDEX idx_up ON users((UPPER(name)))，MySQL 内部会自动创建一个不可见的虚拟列（比如叫 func_001），再对它建 B+ 树索引。所以它继承了普通索引的所有规则，也受同样限制。
- 函数必须是确定性的：
UPPER()、TRIM()、CONCAT('a', col)可以；NOW()、RAND()、UUID()直接报错：ERROR 3905: Expression #1 of generated column '' cannot be stored -
EXPLAIN中key字段显示的是虚拟列名（如func_001），不是你写的UPPER(name)，别因此误判索引没生效 - 索引长度仍受限于
innodb_large_prefix和页大小：对TEXT或超长VARCHAR做UPPER()，可能建索引失败或被自动截断
函数索引只对等值和明确范围有效，LIKE 场景基本无效
很多人以为加了 UPPER(name) 索引后，WHERE UPPER(name) LIKE 'ABC%' 就能走索引——实际中大概率不会。优化器只在左侧有固定前缀、且无通配符开头时才可能利用索引做范围扫描。
-
UPPER(name) = 'ABC'✅ 高效命中 -
UPPER(name) >= 'ABC' AND UPPER(name) < 'ABD'✅ 可能走范围扫描（起点明确） -
UPPER(name) LIKE 'ABC%'⚠️ 有时走，但不稳定；UPPER(name) LIKE '%BC%'或UPPER(name) LIKE '%bc'❌ 绝对不走 - 模糊搜索强需求场景，函数索引不是解药：该上
FULLTEXT、前置分词落库，或引入 Elasticsearch
验证是否真走函数索引，不能只看 EXPLAIN 的 key
EXPLAIN 显示 key 有值，不代表函数索引被真正用于过滤。因为优化器可能选了这个索引，却只用它回表，而没用函数表达式本身做条件筛选。
- 务必加
FORMAT=JSON：执行EXPLAIN FORMAT=JSON SELECT ...，检查used_key_parts字段是否包含函数索引对应的虚拟列名（如["func_001"]） - 对比
rows和实际扫描行数：如果rows很大但结果集很小，说明索引没起到过滤作用 - 字符集影响容易被忽略：在
utf8mb4_0900_as_cs这类大小写敏感排序规则下，UPPER('a')和UPPER('A')结果一致，索引仍有效；但若用COLLATE utf8mb4_bin对比，需确保函数和查询逻辑严格对齐
函数索引不是银弹，它是把运行时计算提前固化到索引结构里的权衡方案。升级到 8.0 后，别急着批量加 (UPPER(col))，先确认版本 ≥ 8.0.13、函数确定性达标、查询模式匹配、且 EXPLAIN FORMAT=JSON 真正验证过效果——否则很可能白建，还拖慢 DML 性能。
