mysql 8.0未新增字符串函数，而是通过函数索引机制使upper()、lower()等既有字符串函数可走索引，前提是建索引、查询表达式字面完全一致，并经explain验证命中。
MySQL 8.0 没有新增“字符串函数”作为独立一类性能优化工具。真正带来性能提升的，是函数索引（Functional Index）机制，它让已有字符串函数（如 UPPER()、LOWER()、SUBSTRING()、TRIM()）能在 WHERE 或 ORDER BY 中走索引——前提是用对、建对、查对。
函数索引不是新函数，而是让旧函数能走索引
很多人误以为 MySQL 8.0 “新增了高性能字符串函数”，其实 UPPER()、LOWER() 这些函数从很早版本就存在。8.0 的突破在于允许对它们的计算结果建索引，从而避免全表扫描。
- 建索引前：
SELECT * FROM users WHERE UPPER(name) = 'JOHN';—— 必须对每行计算UPPER(name)，无法使用普通索引 - 建索引后：
CREATE INDEX idx_upper_name ON users ((UPPER(name)));—— 同样查询可直接定位，响应时间从秒级降到毫秒级
哪些字符串函数能用于函数索引？只看确定性，不看名字新旧
能否建函数索引，和函数是否“新”无关，只取决于它是否满足确定性（deterministic）、无副作用、可比较。MySQL 内部复用生成列逻辑，所以可用函数列表与 GENERATED ALWAYS AS 列一致。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- ✅ 安全可用：
UPPER()、LOWER()、TRIM()、SUBSTRING()、LEFT()、RIGHT()、CONCAT()（参数全为列或常量）、REPLACE()（第三个参数不能含子查询） - ❌ 绝对禁用：
UUID()、RAND()、USER()、VERSION()—— 非确定性，建索引会直接报错 - ⚠️ 注意隐式类型转换：
CONCAT(col1, col2)若两列类型不同（如VARCHAR+INT），可能触发隐式转换导致索引失效；建议显式CAST
WHERE 条件必须字面完全匹配，连空格都不能差
函数索引不推理语义，只做表达式字面匹配。哪怕多一个空格、大小写不一致、括号位置不对，都命中失败。
- ✅ 建了
((UPPER(name)))，只有WHERE UPPER(name) = 'JOHN'能走索引 - ❌
WHERE upper(name) = 'JOHN'（小写函数名）—— 在严格模式下语法错误，非严格模式下不走索引 - ❌
WHERE UPPER( name ) = 'JOHN'（空格）—— 表达式字面不一致，优化器不识别 - ❌
WHERE name = 'john'（没套函数）—— 完全不触发函数索引，走的是普通索引（如果有）或全表扫描 - ❌
WHERE UPPER(name) LIKE 'JO%'——LIKE带通配符，无法下推到函数索引
验证是否真生效：别信 DDL，要看 EXPLAIN
执行 CREATE INDEX 成功 ≠ 查询就走索引。必须用 EXPLAIN 看 key 字段是否显示索引名，且 type 是 ref 或 range。
- 正确命中：
EXPLAIN SELECT * FROM users WHERE UPPER(name) = 'JOHN';→key: idx_upper_name - 未命中：
EXPLAIN SELECT * FROM users WHERE name = 'john';→key: NULL，即使有函数索引也无用 - 注意：如果表上有普通
name索引，且查询条件是name = 'john'，优化器可能选它而非函数索引——这是合理行为，不是 bug
函数索引的真正门槛不在语法，而在表达式一致性控制：开发写查询、ORM 拼 SQL、应用层处理参数时，稍有不慎（比如自动转小写、加空格、用 ilike 伪语法），索引就形同虚设。它不像普通索引那样“宽容”，而是一个精确匹配的硬约束。
