MySQL 时间范围查询为什么没有用上索引

我排查过一类很容易误判的慢查询：created_at 明明有普通索引，按一天或一周筛选时，执行计划却没有选它。先给结论：把时间列保持为裸列，改成“左闭右开”的范围，例如 created_at >= '2026-10-20 00:00:00' AND created_at ；然后用 EXPLAIN 同时看 possible_keys、key、type 和 rows。如果时间范围覆盖了大部分数据，优化器仍可能认为全表扫描更便宜，这不等于索引失效。

先确认索引和查询列真的对应

时间字段上单独建了索引却没生效，90%以上的场景都是查询条件匹配的行数占表总记录数比例过高，超过了MySQL优化器判定的索引使用阈值，优化器自动放弃走时间索引选择全表扫描。

遇到“没走索引”时，我不会马上加 hint，而是先确认表结构。很多问题最后不是优化器拒绝索引，而是索引建在另一列、查询用了别名列，或者实际执行的 SQL 与代码里看到的版本不同。

-- 先看表结构和索引，确认时间列与索引名称对应
SHOW CREATE TABLE orders;
SHOW INDEX FROM orders;

-- 只保留必要列，模拟按时间范围读取订单
SELECT id, user_id, created_at
FROM orders
WHERE created_at >= '2026-10-20 00:00:00'
  AND created_at 

这里的关键不是索引名字必须叫 idx_created_at，而是索引的键列要与谓词中的时间列对应。MySQL 文档把这种由比较条件形成的区间称为 range condition；对 B-Tree 索引而言，>=、、BETWEEN 等比较都可能形成范围。

用 EXPLAIN 分清候选索引和实际索引

possible_keys 表示优化器认为可以考虑的索引，key 才是本次计划实际选择的索引。两者都为空，优先查列、表达式和索引定义；possible_keys 有值而 key 为空，则要继续看范围大小、统计信息和回表成本。

-- 用同一组边界观察优化器给出的访问计划
EXPLAIN
SELECT id, user_id, created_at
FROM orders
WHERE created_at >= '2026-10-20 00:00:00'
  AND created_at = '2026-10-20 00:00:00'
  AND created_at 

理想情况下，单列时间索引常见的是 type=range，key 指向时间索引，rows 也明显小于整表规模。但这只是方向，不是硬性验收条件：返回行很多时，随机回表成本可能让全表扫描更合算。MySQL 官方说明 EXPLAIN 展示的是优化器对执行计划的判断，因此应结合实际数据分布理解。

最容易让时间索引失去范围条件的三种写法

第一种是把列包在函数里。下面的写法先对每一行计算日期，再比较结果，优化器不一定能把它还原成原始列上的连续区间。更稳定的写法是把日期边界算在参数侧。

-- 问题写法：函数包住索引列，索引列不再是直接比较对象
SELECT COUNT(*)
FROM orders
WHERE DATE(created_at) = '2026-10-20';

-- 推荐写法：只比较裸列，把一天表达成左闭右开区间
SELECT COUNT(*)
FROM orders
WHERE created_at >= '2026-10-20 00:00:00'
  AND created_at 

第二种是用 BETWEEN 拼接每天的结束时间。它包含右端点，微秒精度、应用层格式和下一天数据都可能带来边界歧义，所以我更倾向于 >= start AND 。第三种是对列做字符串截取、时区转换或隐式类型转换；这类写法应先统一参数类型，再让列直接参与比较。

复合索引里，等值列通常要排在时间范围前

如果业务查询总是先限定租户，再查时间段，单列 created_at 不一定是最贴合的索引。比如索引是 (tenant_id, created_at)，查询先用 tenant_id = 42 缩小范围，再对 created_at 做区间，通常更符合联合键的有序性。

-- 复合索引把等值条件放在前面，时间范围放在后面
CREATE INDEX idx_orders_tenant_created
ON orders (tenant_id, created_at);

-- 先锁定租户，再扫描该租户的时间区间
EXPLAIN
SELECT id, user_id, created_at
FROM orders
WHERE tenant_id = 42
  AND created_at >= '2026-10-20 00:00:00'
  AND created_at 

但不要把“有联合索引”理解成“必然使用联合索引”。如果日期跨度覆盖了绝大多数记录，或者统计信息估算的返回量很大，优化器可能选择别的计划。此时先看 key_len、rows 和实际过滤条件，再决定是否需要调整索引，而不是只盯着 type 一个字段。

修复后做一次反向验证

改写查询后，仍用原来的参数重新执行 EXPLAIN，至少对照四件事：possible_keys 是否出现目标索引、key 是否真的选中、访问类型是否从 ALL 变成更合适的范围访问、rows 估算是否下降。如果这些没有改善，再回到数据分布、复合索引前缀和统计信息，不要用强制索引掩盖问题。

常见问题

时间列上有索引，为什么 DATE(created_at) 还是慢？

因为查询先对列做函数计算，原始索引列不再直接形成连续范围。把日期转换为起止时间参数，保留 created_at 裸列比较。

BETWEEN 一定不能用索引吗？

不是。MySQL 可以把 BETWEEN 作为范围条件；问题通常在于右端点语义和参数精度。按时间窗口查询时，左闭右开的写法更不容易重复或漏掉边界记录。

EXPLAIN 没走索引就一定是索引失效吗？

不一定。若范围覆盖大量行，全表扫描可能是成本更低的计划。先分清“没有候选索引”和“候选索引成本不划算”，再决定是否修改索引。