WHERE中对索引列使用DATE()、YEAR()等函数会导致索引失效，因MySQL无法将B+树有序原始值映射到无序计算结果；应改用范围条件如create_time >= '2026-03-13' AND create_time

因为索引里存的是 create_time 的原始值（比如 '2026-03-13 14:22:05'），而 DATE(create_time) 是运行时逐行计算出的新值，MySQL 无法把 B+ 树里有序的原始时间值，直接映射到无序的“日期截断结果”上——优化器干脆放弃索引，选择全表扫描。

WHERE 中用 DATE() / YEAR() 等函数为什么一定失效

索引不是“能算就能用”，而是依赖字段原始值的有序结构。一旦在 WHERE 左侧对索引列调用函数，就等于告诉 MySQL：“别查索引了，每行都算一遍再比”。
常见失效写法包括：

• WHERE DATE(create_time) = '2026-03-13'
• WHERE YEAR(create_time) = 2026
• WHERE DATE_ADD(create_time, INTERVAL 1 DAY) > NOW()

这些都会让 key 字段在 EXPLAIN 中显示为 NULL，type 降为 ALL。

正确改法：把函数逻辑转成范围条件

核心是让索引列以“未加工、可比较”的形式出现在 WHERE 左侧。日期截断最典型的替代方案就是用半开区间：

create_time

• YEAR(create_time) = 2026 → create_time >= '2026-01-01' AND create_time
• HOUR(create_time) = 14 → create_time >= '2026-08-11 14:00:00' AND create_time （需配合具体日期）

MySQL 8.0+ 函数索引不是万能解药

虽然可以建 CREATE INDEX idx_create_date ON orders ((DATE(create_time)))，但它有明确代价：

• 该索引只对 WHERE DATE(create_time) = ... 生效，对 WHERE create_time > ... 完全无效
• 写入时要额外维护虚拟列和索引，TPS 下降明显
• 不能覆盖 ORDER BY DATE(create_time) 或 GROUP BY DATE(create_time) 场景（除非显式引用该函数索引列）

真正需要高频按日期截断查询的业务，更稳妥的做法是冗余一个 create_date DATE 字段，单独建索引并保持同步。

最容易被忽略的一点：即使你写了范围条件，如果字段类型是 DATETIME 却传了字符串 '2026-03-13'（没带时分秒），MySQL 可能隐式补零或触发类型转换——务必统一用 '2026-03-13 00:00:00' 和 '2026-03-14 00:00:00' 这种完整格式，避免意外。