SELECT日期查询本身不会导致索引失效，真正让索引失效的是WHERE条件中对日期列使用函数（如DATE()）或隐式类型转换；联合索引需满足最左匹配原则，范围查询后列无法被索引覆盖。
SELECT 日期查询本身不会导致索引失效，真正让索引失效的是 WHERE 条件中对日期列用了函数（比如 DATE()、YEAR()、MONTH()）或隐式类型转换。
WHERE 中用 DATE(create_time) 是最常见踩坑点
索引是按原始值（如 '2024-06-15 14:23:01'）有序存储的，一旦套上 DATE()，优化器就无法直接比对 B+ 树节点——相当于把整棵树拆开再逐行算一遍。
- ❌ 失效写法：
WHERE DATE(create_time) = '2024-06-15' - ✅ 正确写法：
WHERE create_time >= '2024-06-15' AND create_time - ⚠️ 注意：MySQL 8.0+ 支持函数索引（
CREATE INDEX idx ON t(DATE(create_time))），但写入开销大，且只对这个特定函数有效，不推荐日常使用
字符串格式的日期字面量引发隐式类型转换
当 create_time 是 DATETIME 类型，却用字符串加引号传参，MySQL 有时能“猜对”，但不可靠；PostgreSQL 或 Oracle 直接报错或跳过索引。
- ❌ 危险写法：
WHERE create_time = '2024-06-15'（缺失时分秒，触发隐式截断+类型转换） - ✅ 安全写法：
WHERE create_time >= '2024-06-15 00:00:00' AND create_time - ? 更稳妥：统一用
DATE()函数处理查询值（而非字段），例如WHERE DATE(create_time) = CURDATE()在某些版本仍可能走索引，但不如范围写法稳定
联合索引里日期列位置不当
如果索引是 (user_id, create_time)，而查询只写了 WHERE create_time > '2024-01-01'，那整个索引完全失效——因为跳过了最左列 user_id。
- ✅ 要让该索引生效，必须带上
user_id条件，例如：WHERE user_id = 123 AND create_time > '2024-01-01' - ✅ 如果经常单独查日期，应单独建索引：
CREATE INDEX idx_create_time ON t(create_time) - ⚠️ 注意：范围查询（如
>）之后的联合索引列不再生效，所以(status, create_time, id)中，WHERE status = 1 AND create_time > '2024-01-01'无法利用id列做索引覆盖
真正要盯住的不是“SELECT 日期”，而是 WHERE 里怎么写条件。哪怕字段上有索引，只要条件破坏了 B+ 树的有序前提，优化器就会当场放弃——它宁可全表扫描，也不愿在树上做无效跳跃。
