时间范围查询需为时间字段建立单列索引或将其置于联合索引最左位，避免函数操作导致索引失效，应改用范围查询替代date/year等函数。
时间范围查询是数据库中最常见的性能瓶颈之一，尤其在日志、订单、监控等按时间递增写入的场景中。不加索引或索引设计不当，会导致全表扫描，查询从毫秒级飙升至数秒甚至超时。
时间字段必须单独建索引或作为联合索引最左前缀
如果经常执行类似 WHERE create_time BETWEEN '2024-01-01' AND '2024-06-30' 的查询，create_time 字段必须有索引。单列索引即可生效；若已有联合索引（如 (user_id, create_time)），但查询只过滤 create_time，该索引将无法使用——因为 B+ 树索引要求最左匹配。
- ✅ 正确：建立单列索引
INDEX idx_create_time (create_time) - ✅ 正确：联合索引按时间字段开头，如
INDEX idx_time_status (create_time, status)，支持时间范围 + 状态等后续条件 - ❌ 错误：仅存在
(status, create_time)索引，而查询没指定 status —— 索引失效
避免在时间字段上使用函数或表达式
对时间字段做计算会直接导致索引失效。例如：WHERE DATE(create_time) = '2024-05-20' 或 WHERE YEAR(create_time) = 2024，mysql 无法用索引定位具体行，只能全表扫描。
- ✅ 改写为范围查询：
WHERE create_time >= '2024-05-20 00:00:00' AND create_time - ✅ 查询某月数据：
WHERE create_time >= '2024-05-01' AND create_time - ⚠️ 注意：用
和 <code> 组合比 <code>BETWEEN更利于优化器估算，也避免边界时间精度问题
高频时间范围 + 高区分度字段，优先建组合索引
当查询同时带时间范围和另一个高选择性条件（如 tenant_id、device_id）时，组合索引能显著减少扫描行数。关键原则是：把等值条件放前面，范围条件放后面。
- ✅ 推荐顺序：
INDEX idx_tenant_time (tenant_id, create_time)，适用于WHERE tenant_id = 123 AND create_time > '2024-01-01' - ✅ 若还需查状态，可扩展为：
INDEX idx_tenant_time_status (tenant_id, create_time, status)，覆盖查询更彻底 - ❌ 不要写成
(create_time, tenant_id)——时间范围后无法继续用 tenant_id 索引筛选
定期清理或归档旧数据，配合分区表提升效率
对于亿级大表，即使有索引，扫描几十万行仍慢。此时可考虑按时间分区（如每月一个分区），让优化器自动裁剪无关分区；或把历史数据归档到冷表，主表保持轻量。
- ✅ MySQL 8.0+ 支持 RANGE 分区：
PARTITION BY RANGE (TO_DAYS(create_time)) - ✅ 归档脚本示例：
INSERT INTO orders_archive SELECT * FROM orders WHERE create_time - ⚠️ 注意：分区不是银弹，需结合业务读写模式评估；小表分区反而增加管理开销