自定义函数必然导致索引失效，因MySQL优化器无法下推或估算其逻辑，只能全表扫描；应改用STORED生成列预计算并建索引。
WHERE里调用自定义函数必然让索引失效
MySQL无法在B+树索引中直接匹配自定义函数的计算结果，优化器只能对每一行执行该函数后再比对——这等于放弃索引跳转能力，强制全表扫描。哪怕函数逻辑极简单（比如fn_trim_prefix(name)），只要它作用于索引列，key就会是NULL，type变成ALL。
自定义函数 vs 内置函数，失效逻辑完全一致
很多人误以为只有YEAR()、DATE()这类内置函数才导致失效，其实自定义函数更危险：内置函数至少有优化器“认知”，而UDF（User Defined Function）完全黑盒，优化器连估算成本都做不到，往往直接跳过索引。
- ❌ 失效写法：
SELECT * FROM users WHERE fn_upper_name(username) = 'LISA' - ✅ 替代方案：把转换逻辑前置到应用层或INSERT/UPDATE时固化，查询时直接匹配已处理值（如
username_normalized字段） - ⚠️ 注意：即使你给
fn_upper_name(username)建了函数索引（MySQL 8.0+），也仅对该表达式生效，无法用于ORDER BY username或WHERE username LIKE 'lis%'
为什么不能像内置函数那样被“下推”优化？
内置函数（如UPPER()）在优化器中有明确的等价重写规则，某些场景下可尝试常量折叠或索引列映射；但自定义函数没有注册语义信息，MySQL既不知道它是否确定性（DETERMINISTIC），也不知道输入输出是否一对一，更无法做谓词下推。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 函数必须声明为
DETERMINISTIC才能被创建，但这不等于优化器会信任它可用于索引查找 -
SHOW CREATE FUNCTION fn_upper_name能看到声明，但EXPLAIN里不会出现任何与该函数相关的索引提示 - 哪怕函数体只有一行
RETURN UPPER(str)，优化器仍视其为不可下推的黑箱
真要查归一化值，优先走冗余字段而非函数
业务中常见需求是“忽略大小写查用户名”或“按拼音首字母分组”，这类逻辑别依赖运行时函数，而应在写入时生成确定性衍生字段并建索引。
- 加列：
ALTER TABLE users ADD COLUMN username_lower VARCHAR(64) GENERATED ALWAYS AS (LOWER(username)) STORED - 建索引：
CREATE INDEX idx_username_lower ON users (username_lower) - 查的时候写：
WHERE username_lower = 'lisa'——这时type才是ref，key显示真实索引名 - 避免用
VIRTUAL列：MySQL 5.7/8.0对虚拟列索引的支持不稳定，STORED更稳妥
最易被忽略的是：函数索引（CREATE INDEX ... ((fn(x)))）和生成列索引不是一回事——前者只加速该函数表达式本身，后者让归一化值真正落地为物理列，能参与覆盖索引、排序、范围扫描等所有索引能力。
