MySQL 日期条件怎样写才能利用索引

MySQL 日期查询能不能利用索引，关键通常不在“日期函数有没有写对”，而在于优化器能否直接从索引列上确定一段连续范围。把 created_at 写成 DATE(created_at) = '2026-11-14' 很直观，但它先对列逐行取日期；更稳妥的写法是保留列本身，改成从当天零点开始、到下一天零点之前结束的半开区间。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

先记住一句话：让索引列保持原样，用常量边界去比较它。按天查询优先写成 created_at >= 起点 AND created_at 。

先看问题现场：日期条件为什么看似一样，计划却不同

假设订单表有一个常见索引：

-- 日期列单独建索引，便于对比不同 WHERE 写法
CREATE INDEX idx_orders_created_at ON orders (created_at);

-- 需求：查询 2026-11-14 这一天创建的订单
SELECT id, amount
FROM orders
WHERE DATE(created_at) = '2026-11-14';

这条 SQL 的业务含义没有错，但数据库需要把每行的 created_at 先计算成日期，再判断是否等于目标日期。索引树里存的是原始日期时间值，条件没有直接给出原始值的连续区间，优化器就不容易把它转成一个简单的范围扫描。

日期列类型也要先确认：DATE 没有时分秒，按天等值比较通常已经足够；DATETIME 和 TIMESTAMP 包含时间部分，不能把“某一天”误写成只比较一个零点值。MySQL 官方文档说明，索引可以帮助定位满足 WHERE 条件的行，但是否使用还取决于条件形式、选择性和读取成本。

第一层检查：不要在索引列上套日期函数

下面几类写法表达的都是“按日期筛选”，但它们都会把函数放在列上：

-- 这些写法先计算索引列，再做比较，排查慢查询时应优先改写
SELECT * FROM orders WHERE DATE(created_at) = '2026-11-14';
SELECT * FROM orders WHERE YEAR(created_at) = 2026 AND MONTH(created_at) = 11;
SELECT * FROM orders WHERE DATE_FORMAT(created_at, '%Y-%m') = '2026-11';

这不等于“只要出现函数就必然全表扫描”，也不等于“索引一定完全失效”。优化器可能选择其它访问方式，某些版本和索引设计也有更复杂的能力；但在常规单列 B-Tree 索引场景里，先把列从函数里拿出来，是最容易解释、最容易复用的改动。

反过来，把函数放到边界常量一侧通常更合理。例如应用传入月份的第一天后，可以在应用层或参数层算出下个月第一天，再比较原始列：

-- 边界值由调用方提前准备，索引列保持原始 created_at
SELECT id, amount
FROM orders
WHERE created_at >= '2026-11-01 00:00:00'
  AND created_at 

第二层检查：按天查询使用半开区间

“某一天”不是从零点到 23:59:59 这么简单。DATETIME 支持小数秒时，硬编码当天最后一秒可能漏掉更精细的值；即使当前数据没有微秒，闭区间也让边界计算变得脆弱。

推荐的表达方式是：

-- 包含当天零点，排除下一天零点，覆盖当天全部时间
SELECT id, amount
FROM orders
WHERE created_at >= '2026-11-14 00:00:00'
  AND created_at 

这里的左边界包含，右边界不包含，所以 2026-11-15 00:00:00 不会被错误地算进前一天；任意小于这个值的当天时间都会命中。这个写法对按天、按周、按月都成立，只需要把两个边界换成相邻粒度：

-- 月报使用下个月第一天作为排除边界，不需要计算本月最后一秒
SELECT COUNT(*) AS order_count
FROM orders
WHERE created_at >= '2026-11-01 00:00:00'
  AND created_at 

第三层检查：BETWEEN 和边界类型是否符合业务语义

BETWEEN a AND b 是包含两端的。它适合明确需要闭区间的业务规则，但不适合直接拿来表示连续日期粒度，因为下一个查询区间可能和上一个区间在边界值上重叠。

-- BETWEEN 两端都包含；这里的结束值必须由业务明确给出
SELECT id
FROM orders
WHERE created_at BETWEEN '2026-11-14 00:00:00'
                      AND '2026-11-14 23:59:59';

-- 连续日区间更适合左闭右开，前后区间自然相邻且不重叠
SELECT id
FROM orders
WHERE created_at >= '2026-11-14 00:00:00'
  AND created_at 

如果日期参数来自应用服务，还要确认参数类型与列类型一致。把字符串、日期、时间戳混在一起交给隐式转换，可能带来时区或精度误差，也可能让优化器面对额外的类型转换。最稳妥的做法是：在同一时区计算边界，绑定与列语义一致的参数，并把边界值作为参数传入。

对于 TIMESTAMP，还要特别留意会话时区；同一个文本日期在不同会话设置下可能对应不同的时间点。文章讨论的是条件形状和索引范围，不替代业务对时区的定义。时区没有先定清楚，换成任何索引写法都可能得到“快但不对”的结果。

第四层检查：用 EXPLAIN 区分“索引可用”和“索引值得用”

改写完成后，不要只看 SQL 文本。用 EXPLAIN 对比函数写法和范围写法：

-- 用 EXPLAIN 查看优化器为按天范围选择的访问方式
EXPLAIN
SELECT id, amount
FROM orders
WHERE created_at >= '2026-11-14 00:00:00'
  AND created_at 

重点看几个字段：

MySQL 官方文档也提醒，索引并不是任何时候都更快：如果查询要读取表中很大比例的行，顺序读取可能比反复回表更划算。因此“利用索引”应理解为让条件具备可用的范围，而不是强制优化器每次都选择该索引。

联合索引中的日期条件：先看最左侧列

如果索引是 (tenant_id, created_at)，日期范围通常应该和租户等值条件一起出现：

-- 联合索引的第一列先等值限定，第二列再做日期范围
CREATE INDEX idx_orders_tenant_created ON orders (tenant_id, created_at);

SELECT id, amount
FROM orders
WHERE tenant_id = 42
  AND created_at >= '2026-11-14 00:00:00'
  AND created_at 

如果只写日期、不写联合索引的第一列，能否高效使用该索引要看数据分布、版本能力和执行计划，不能把单列索引的直觉直接套过来。MySQL 文档对多列索引强调最左前缀原则；排查时应把索引定义、查询条件和 EXPLAIN 放在一起看。

最后收口：日期索引排查清单

实际落地时，可以先把一个慢查询复制成两个版本：原来的函数条件和半开区间条件。用同一组参数执行 EXPLAIN，再结合真实数据量和返回行数比较。这样既能确认日期边界没有改变，也能避免把“理论上能走索引”误当成“这次查询一定更快”。

相关问题

DATE 列也必须写成半开区间吗？

不一定。DATE 没有时间部分，按某一天等值比较通常已经表达完整语义；半开区间主要解决 DATETIME、TIMESTAMP 的时间边界问题。最终仍应以列类型和执行计划为准。

看到 type=range 就说明查询已经足够快吗？

不是。range 说明使用了范围访问方式，但范围可能覆盖大量记录，回表和排序也可能成为主要成本。还要看 rows、返回列、过滤条件和实际耗时。

能不能用 FORCE INDEX 强制日期索引？

除非已经有充分的执行计划和线上数据证据，否则不建议把强制索引当第一步。先修正日期条件形状、检查统计信息和联合索引顺序，再判断是否需要提示；强制选择错误的索引可能让数据分布变化后的查询更慢。