mysql查询某个日期的数据怎么写SQL语句

在 MySQL 中查询某个具体日期的数据，最核心的前提是确认目标字段的数据类型。如果字段是纯日期类型（DATE），可以直接使用等值条件 WHERE date_column = '2026-10-02' 查询；如果字段包含具体时间（如 DATETIME 或 TIMESTAMP），直接等值匹配只会比对当天的零点零分零秒，导致白天产生的数据全部漏查。此时最高效且准确的做法是采用“左闭右开”的范围查询：WHERE datetime_column >= '2026-10-02 00:00:00' AND datetime_column < '2026-10-03 00:00:00'。这种写法不仅能够完整覆盖当天全天 24 小时的全部数据，还能充分利用数据库索引提升检索性能。

第一步：查看表结构，确认字段数据类型

编写查询语句前，首先要搞清楚表中存储日期的列到底是什么类型。不同类型在底层存储的数据精度完全不同：

• DATE 类型：仅存储年月日，格式为 YYYY-MM-DD（例如 2026-10-02），不包含时分秒。
• DATETIME 类型：包含年月日以及时分秒，格式为 YYYY-MM-DD HH:MM:SS（例如 2026-10-02 14:35:20），甚至包含微秒。
• TIMESTAMP 类型：时间戳类型，同样精确到时分秒，会随数据库时区设置自动转换。

可以通过以下 SQL 语句查看目标表的字段定义：

DESCRIBE orders;
-- 或者使用
SHOW COLUMNS FROM orders LIKE 'created_at';

观察输出结果中 Type 列的定义。这一判断直接决定了后续应该使用等值条件还是范围条件。

第二步：针对纯 DATE 字段的查询写法

如果经过检查，你的数据表列类型为 DATE，那么查询非常直接。因为该字段本身不存储具体时间，每一行记录就是一个单纯的日期值。

1. 单个指定日期查询

SELECT * 
FROM orders 
WHERE order_date = '2026-10-02';

这里的日期字符串建议严格使用标准的 YYYY-MM-DD 格式。虽然 MySQL 支持形如 20261002 的数字或字符串写法，但标准的短横线分隔格式兼容性最好，语义最明确。

2. 查询多个指定日期

如果需要同时查询某几天（例如 2026 年 10 月 1 日和 10 月 2 日）的数据，可以使用 IN 列表：

SELECT * 
FROM orders 
WHERE order_date IN ('2026-10-01', '2026-10-02');

在 DATE 类型的列上建立索引后，上述等值或列表查询的 EXPLAIN 执行计划通常会显示为 ref 或 range，查询耗时极短。

第三步：针对 DATETIME / TIMESTAMP 字段的标准写法

绝大多数业务系统中的创建时间、支付时间或更新时间都是 DATETIME 或 TIMESTAMP 类型。这类字段包含精确的时分秒，如果依然写成 WHERE created_at = '2026-10-02'，MySQL 会隐式将其转换为 2026-10-02 00:00:00。这意味着只有恰好在午夜零点零分零秒生成的记录才会被查出，其余 99.9% 的数据都会被漏掉。

推荐写法：左闭右开范围查询

查询某一天数据的本质，是查询时间落在“当天零点”与“次日零点”之间的全部记录。推荐的标准 SQL 写法如下：

SELECT * 
FROM orders 
WHERE created_at >= '2026-10-02 00:00:00' 
  AND created_at <  '2026-10-03 00:00:00';

这种写法具有两个决定性的优点：

1. 完整覆盖微秒：部分数据库配置了微秒精度（例如 DATETIME(6)），如果使用 BETWEEN ... AND '23:59:59'，发生在 23:59:59.100 到 23:59:59.999 的数据就会被遗漏。而 < '2026-10-03 00:00:00' 则能滴水不漏地包含所有时间。
2. 完美保留索引效率：直接在列名上进行范围比较，不会改变列本身的索引结构，MySQL 可以直接在 B+ 树索引上定位边界并快速扫描。

第四步：为什么不建议使用 DATE(created_at) 函数？

很多开发者为了图省事，会直接在查询条件中对字段套用 DATE() 函数：

-- 看上去很直观，但在生产大表中存在严重性能隐患
SELECT * 
FROM orders 
WHERE DATE(created_at) = '2026-10-02';

这段 SQL 的逻辑虽然正确（将每一行的时分秒截断后再比对），但它违反了数据库索引检索的基本法则：对索引列进行函数计算会导致索引失效。

MySQL 的 B+ 树索引是按照 created_at 原始值的大小有序排列的。当在条件中写了 DATE(created_at) 时，MySQL 无法直接在 B+ 树上进行二分查找定位，必须对表中的每一行记录都读取出来、调用 DATE() 函数计算结果，再与目标字符串比较。这种操作在数据库执行计划中被称为全表扫描（type: ALL）。

第五步：常见场景扩展与动态日期处理

在日常业务开发中，除了查询硬编码的固定日期（如 2026-10-02），更多时候需要查询相对于当前时间的“今天”、“昨天”或“指定某天”。此时如何编写既动态又走索引的 SQL 语句？

1. 查询“今天”产生的数据

不要使用 WHERE DATE(created_at) = CURDATE()。正确做法是利用 CURDATE()（获取当前日期零点，如 2026-10-02 00:00:00）结合时间间隔运算：

-- 查询今天全天的数据（高效走索引）
SELECT * 
FROM orders 
WHERE created_at >= CURDATE() 
  AND created_at <  CURDATE() + INTERVAL 1 DAY;

这里 CURDATE() 是在查询执行前由 MySQL 计算出的确定性常量，不会对表中的每一行字段执行计算，因此索引完全有效。

2. 查询“昨天”产生的数据

同样的思路，结合 INTERVAL 1 DAY 进行时间推移：

-- 查询昨天全天的数据
SELECT * 
FROM orders 
WHERE created_at >= CURDATE() - INTERVAL 1 DAY 
  AND created_at <  CURDATE();

3. UNIX 时间戳整数存储的查询写法

某些历史系统或特定设计会将时间保存为整数时间戳（例如 1790899200，即从 1970 年开始的秒数）。如果需要查询某一天的数据，很多人的第一反应是写 FROM_UNIXTIME(created_time)，但这同样会对列施加函数导致索引失效。

正确的优化方式是将查询条件转化为时间戳范围，保持列名原生干净：

-- 查询 2026-10-02 全天对应的时间戳数据
SELECT * 
FROM orders 
WHERE created_time >= UNIX_TIMESTAMP('2026-10-02 00:00:00') 
  AND created_time <  UNIX_TIMESTAMP('2026-10-03 00:00:00');

UNIX_TIMESTAMP('2026-10-02 00:00:00') 在 SQL 解析阶段被直接计算为固定数字，字段 created_time 上的整型索引能够以极高速度完成检索。

第六步：常见误区与避坑清单

总结

在编写 MySQL 查询某个日期的 SQL 语句时，请牢记核心口诀：先查类型，再选写法；列名不套函数，时间左闭右开。如果是纯 DATE 字段，直接用等值查询；如果是 DATETIME 或 TIMESTAMP 字段，始终坚持使用大于等于当天零点且小于次日零点的范围条件。这样既能保证无论是在微秒精度还是在普通秒级精度下数据都不漏不错，又能最大化发挥 B+ 树索引的检索效能，保障系统在数据量增长时的稳定与快速响应。