sql时间函数本身不直接导致索引失效，真正原因是WHERE子句中对日期字段使用函数（如YEAR()、date()），使数据库无法利用索引的有序性而被迫全表扫描；正确做法是将函数移至比较值右侧，保持字段裸露。
SQL时间函数本身不直接导致索引失效，真正引发性能问题的是red”>在WHERE子句中对日期字段施加函数操作。比如写成 WHERE YEAR(create_time) = 2025 或 WHERE DATE(order_date) >= '2025-01-01'，数据库无法利用 create_time 或 order_date 上的索引，只能全表扫描。
为什么对字段用函数会让索引失效
索引是按字段原始值（如 '2025-06-15 14:22:03'）有序存储的。一旦在查询中对字段执行函数，数据库必须先逐行计算结果，再比对——这破坏了索引的有序性前提。就像查字典时，不能靠“把每个字倒过来再找”，只能老老实实翻页。
- 索引本质是B+树结构，依赖字段原始值的排序关系快速定位
- 函数改变了字段值的表达形式，优化器无法将索引键与函数结果映射匹配
- 即使字段有索引，
WHERE MONTH(pay_time) = 12这类写法也必然触发全表扫描
安全写法：把函数移到比较值一侧
保持字段裸露，把时间计算逻辑放在右边常量上，索引就能生效：
- ❌ 错误：
WHERE DATE(log_time) = '2026-01-05' - ✅ 正确：
WHERE log_time >= '2026-01-05' AND log_time - ❌ 错误：
WHERE YEAR(reg_date) = 2025 - ✅ 正确：
WHERE reg_date >= '2025-01-01' AND reg_date
这种写法明确界定左闭右开区间，既覆盖全天数据，又完全走索引。
特殊场景：范围查询与函数的兼容方案
某些业务确实需要按年/月/周聚合，又想避免全表扫描，可考虑以下替代路径：
- 添加生成列并建索引：mysql 5.7+ 支持
ALTER table t ADD column ym char(7) STOred AS (DATE_FORMAT(create_time, '%Y-%m'));，再对ym建索引 - 使用分区表：按时间字段做 RANGE 分区（如每月一分区），查询时自动剪枝
- 预计算汇总表：每日凌晨跑任务，把日/周/月指标存入宽表，查询直读聚合结果
验证是否走索引的小技巧
执行前加 EXPLaiN 查看执行计划：
- 关注
type列：出现range或ref表示走了索引；ALL就是全表扫描 - 看
key列：显示实际使用的索引名，为空说明没用上 - 留意
Extra列：含using where; Using index是理想状态