对timestamp或datetime字段做范围查询必须建b+tree索引且where中避免函数调用，否则索引失效；正确写法为左闭右开区间；联合索引字段顺序需按区分度高低调整；务必用explain验证索引是否生效。
直接给结论：对 TIMESTAMP 或 DATETIME 字段做范围查询，必须建 B+Tree 普通索引或联合索引，并且 WHERE 条件里避免在该列上用函数（比如 DATE()、YEAR()、DATE_FORMAT()），否则索引失效。
为什么不能在 WHERE 里对时间字段调用函数？
MySQL 无法将函数结果提前映射到索引树节点上。比如 WHERE DATE(created_at) = '2023-01-01'，实际是把每一行的 created_at 先取日期再比对，等于全表扫描——哪怕你建了索引也没用。
- 正确写法是改用左闭右开区间：
WHERE created_at >= '2023-01-01 00:00:00' AND created_at -
BETWEEN看似简洁，但它是闭区间，容易漏掉毫秒级数据（如'2023-01-01 23:59:59.999'被截断），不如显式用控制边界更可靠 - 如果字段是
TIMESTAMP，还要注意时区：写入值会转为 UTC 存储，查询时也按当前会话时区转换，建议统一用CONVERT_TZ()显式处理，别依赖默认行为
单列索引 vs 联合索引怎么选？
单列索引（如 INDEX idx_created_at (created_at)）够用，前提是查询只过滤时间；但一旦带上其他高频条件（比如状态、类型、用户ID），就得考虑联合索引。
- 联合索引要遵守最左前缀原则：比如
INDEX idx_status_time (status, created_at)，能加速WHERE status = 'paid' AND created_at > '2023-06-01'，但对WHERE created_at > '2023-06-01'单独使用就无效 - 如果经常查「某状态 + 最近 N 天」，把区分度高的字段放前面（比如
status只有 3–5 个值，created_at是高区分度字段），那应该反过来建(created_at, status)，再配合WHERE created_at > ... AND status IN (...)形式，让优化器有机会用上索引范围扫描 - 不要为每个时间字段都单独建索引——写入性能下降、磁盘占用增加，优先合并到已有联合索引中
怎么验证索引真被用了？
光建了索引不等于生效，得看执行计划。对查询加 EXPLAIN 前缀，重点盯三列：
-
type：要是range或更好（ref、const），千万别是ALL（全表扫描） -
key：显示实际使用的索引名，为空说明没走索引 -
rows：预估扫描行数，越小越好；如果比总行数还大，大概率索引没起作用或选错了 - 额外提醒：如果查询里有
OR、多个范围条件（比如两个BETWEEN）、或!=判断，优化器可能干脆放弃索引，改用全表扫描——这种时候得重写逻辑，比如拆成UNION或用IN替代部分范围
真正难的不是建索引，而是让 WHERE 条件和索引结构严丝合缝地咬合。一个括号位置、一个函数调用、甚至一个隐式类型转换（比如把字符串 '2023-01-01' 当作日期用），都可能让整条索引链断裂。动手前先 EXPLAIN 一眼，比猜半天靠谱得多。
