where中对索引列使用函数（如year、upper）会导致索引失效，因b+树存储原始值而非计算结果；应改写为范围查询，使索引列以裸值出现在操作符左侧。

WHERE里用YEAR(create_time)这类函数，索引就废了

因为索引B+树里存的是create_time的原始值（比如'2026-09-21 14:30:00'），不是YEAR()算出来的2026。优化器没法拿着2026去B+树里二分查找——树里根本没有这个“年份序列”，只有完整时间戳的有序排列。

它只能退化为全表扫描：逐行取出create_time，调用YEAR()函数，再比对结果。哪怕表只有1万行，也要执行1万次函数调用+1万次判断。

常见失效写法包括：

• WHERE DATE(create_time) = '2026-09-21'
• WHERE UPPER(name) = 'ABC'
• WHERE id + 1 = 100
• WHERE SUBSTR(phone, 1, 3) = '138'

怎么改才能让索引重新生效

核心原则：让索引列以“裸值”形式出现在=、>=等操作符左侧，把计算逻辑挪到右侧或改写为范围条件。

例如：

• 原句：WHERE YEAR(create_time) = 2026 → 改为：WHERE create_time >= '2026-01-01' AND create_time
• 原句：WHERE DATE(create_time) = '2026-09-21' → 改为：WHERE create_time >= '2026-09-21 00:00:00' AND create_time
• 原句：WHERE id + 1 = 100 → 改为：WHERE id = 99

注意：BETWEEN写法容易漏掉边界精度（比如BETWEEN '2026-09-21' AND '2026-09-21'只查当天0点），推荐用左闭右开区间更可控。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

MySQL 8.0+ 的CREATE INDEX ... (UPPER(name))能救急吗

可以，但限制极多，不能当常规解法用。

函数索引生效的前提是：

• 查询中使用的函数表达式必须和索引定义**字符级完全一致**，空格、大小写、参数顺序都不能差；
• 只支持确定性函数（UPPER、SUBSTR、TRIM等），不支持NOW()、RAND()；
• ORDER BY UPPER(name)不会自动利用该索引，除非语句里也明确写了ORDER BY UPPER(name)；
• 备份恢复、主从同步、低版本兼容性都可能出问题。

真要用，先在测试环境跑EXPLAIN确认key字段确实命中了函数索引名，别凭感觉。

EXPLAIN里看到type=ALL就一定是函数惹的祸吗

不一定。虽然函数运算是高频原因，但type=ALL只是表征“全表扫描”，背后可能还有别的根因：

• 联合索引没走最左前缀，比如索引是(user_id, status, create_time)，但WHERE status = 1跳过了user_id；
• 隐式类型转换，比如WHERE user_id = '123'（user_id是INT），MySQL会把每行user_id转字符串再比，索引失效；
• OR条件里混入了无索引列，比如WHERE indexed_col = 1 OR unindexed_col = 'x'；
• 统计信息过期，ANALYZE TABLE后rows预估可能变化，type也可能变。

函数运算的问题最容易被忽略，因为它看起来“逻辑正确”；但只要WHERE里出现任何对索引列的包裹或计算，第一反应就该是把它拎出来单独验一遍EXPLAIN。