索引会完全失效，因为函数破坏了b+树索引依赖的有序性与原始值形态，导致优化器无法使用二分查找，只能全表扫描。
MySQL 对索引列使用内置函数（如 DATE()、UPPER()、YEAR() 等）时，索引会完全失效——不是“部分降级”，而是直接退化为全表扫描（type=ALL）。根本原因不是 MySQL “故意不认索引”，而是函数破坏了 B+ 树索引赖以工作的前提：有序性与值的原始形态。
为什么函数会让索引无法参与定位
B+ 树索引中存储的是字段的原始值（例如 create_time 存的是 '2024-06-01 14:23:05'），且按该原始值严格排序。当写 WHERE DATE(create_time) = '2024-06-01'，MySQL 必须对每一行的 create_time 先调用 DATE() 函数，再和常量比较。这个过程相当于在内存里临时构造一个新序列，而这个序列和索引树里的原始排序毫无关系。优化器没法用索引的二分查找或范围跳转，只能逐行计算、逐行判断。
这和“把电话簿按姓名排序后，却问‘姓氏是张的人里谁生日是6月1日？’”一样——你手上有按姓名排好的本子，但问题要求先拆解姓名、再查生日，原有序结构就废了。
-
WHERE UPPER(name) = 'JOHN'→ 索引存的是'john'或'John'原样，UPPER()后才统一，无法对齐 -
WHERE UNIX_TIMESTAMP(created_at) > 1717200000→ 索引里是 datetime，函数输出是 int，类型和顺序都错位 -
WHERE SUBSTR(phone, 1, 3) = '138'→ 索引按完整 phone 排序，前缀提取后失去有序映射
哪些函数操作属于“绝对不能碰”的高危写法
只要出现在 WHERE 或 ON 子句左侧的索引列上，以下操作一律导致索引失效：
- 日期函数：
DATE()、YEAR()、MONTH()、HOUR()、DATE_ADD()（当用于索引列时） - 字符串函数：
UPPER()、LOWER()、SUBSTR()、TRIM()、CONCAT()（如CONCAT(name, '')） - 数学/类型转换：
CAST()、CONVERT()、ABS()、隐式数字转字符串（如WHERE status = '1'而 status 是TINYINT，通常可接受；但反过来WHERE user_id = 123而user_id是VARCHAR就必然失效）
注意：LIKE 'xxx%' 不算函数，它能走索引；但 LIKE '%xxx' 是左模糊，属于“无法利用前缀有序性”，和函数失效逻辑不同，但结果都是 type=ALL。
怎么改写才能让索引重新生效
核心原则：把函数从索引列“挪到常量侧”，让索引列保持裸露、可比对的原始状态。
- ❌
WHERE DATE(create_time) = '2024-06-01'
✅WHERE create_time >= '2024-06-01 00:00:00' AND create_time - ❌
WHERE UPPER(name) = 'JOHN'
✅ 确保写入时统一大小写，查询用WHERE name = 'john'；或建函数索引（MySQL 8.0.13+）：CREATE INDEX idx_name_upper ON t_user ((UPPER(name))) - ❌
WHERE status + 0 = 1（假设 status 是字符串）
✅ 改列类型为TINYINT，或确保传参带引号：WHERE status = '1'
函数索引虽能解部分燃眉之急，但它本身有额外存储开销，且只对**明确指定的函数表达式**生效（(UPPER(name)) 的索引对 LOWER(name) 无效），不能替代规范的数据类型设计和查询习惯。
EXPLAIN 验证时最该盯住的两个字段
执行 EXPLAIN 后，别只扫一眼有没有 key，重点看：
-
type字段：必须是ref、range、const才算有效利用索引；ALL或index就是失效信号 -
key字段：值为NULL表示完全没用索引；非NULL但rows接近总行数，说明索引被选中但效果极差（比如只过滤掉几行） - 顺带看
Extra：出现Using filesort或Using temporary往往是函数导致排序/分组逻辑无法下推到索引层
真正容易被忽略的点是：即使 key 显示用了某个索引，如果 key_len 远小于该索引定义长度（比如联合索引 (a,b,c) 的理论最大 key_len 是 100，但实际只有 10），大概率是左侧某列因函数或类型问题被跳过了——这时索引只是“半残”地参与，性能仍堪忧。
