数据库查询当天时间数据的SQL语句应该怎么写？

在数据库管理与数据分析中,查询当天的数据是一项极为常见且重要的操作，无论是生成每日业务报表、监控系统实时活动，还是筛选特定时间范围内的用户行为，都需要高效、准确地获取当天记录，由于不同的数据库管理系统（DBMS）提供了不同的日期时间函数和语法，掌握主流数据库的查询方法至关重要，本文将详细介绍在几种主流数据库中如何查询当天数据，并探讨相关的最佳实践。

MySQL 数据库查询当天数据

MySQL 提供了丰富的日期时间函数，查询当天数据通常使用 CURDATE() 或 NOW() 函数。CURDATE() 仅返回当前日期，而 NOW() 返回当前的日期和时间。

最佳实践：使用范围查询
为了确保查询能够充分利用索引，提高性能，推荐使用 BETWEEN...AND... 或 >= 和 < 的组合来定义一个时间范围，这种方法避免了在 WHERE 子句中对列使用函数，从而不会导致索引失效。

假设有一个订单表 orders，其中包含一个 DATETIME 类型的 create_time 列。

-- 方法一：使用 >= 和 < (推荐)
SELECT * FROM orders
WHERE create_time >= CURDATE() AND create_time < CURDATE() + INTERVAL 1 DAY;
-- 方法二：使用 BETWEEN AND (注意：BETWEEN 包含两端，所以下限是当天0点，上限是第二天0点)
SELECT * FROM orders
WHERE create_time BETWEEN CURDATE() AND CURDATE() + INTERVAL 1 DAY;

这种方法虽然直观，但有一个显著的性能缺点：DATE(create_time) 会对表中的每一行数据都进行一次函数计算，这将导致 create_time 列上的索引失效，在数据量大的情况下会引发全表扫描，效率低下。

-- 不推荐在数据量大时使用
SELECT * FROM orders WHERE DATE(create_time) = CURDATE();

PostgreSQL 数据库查询当天数据

PostgreSQL 同样提供了强大的日期时间处理能力，其标准 SQL 函数 CURRENT_DATE 用于获取当前日期。

PostgreSQL 的 date_trunc 函数可以非常方便地将时间戳截断到指定的精度（如天、小时、分钟等）。

假设有一个日志表 logs，包含 TIMESTAMP 类型的 created_at 列。

-- 方法一：使用 date_trunc 函数 (清晰直观)
SELECT * FROM logs
WHERE date_trunc('day', created_at) = CURRENT_DATE;
-- 方法二：使用范围查询 (性能更优，同MySQL)
SELECT * FROM logs
WHERE created_at >= CURRENT_DATE AND created_at < CURRENT_DATE + INTERVAL '1 day';

尽管 date_trunc 方法很常用，但出于与MySQL中相同的性能考虑，当处理海量数据时，范围查询依然是更优的选择。

SQL Server 数据库查询当天数据

在 SQL Server 中，可以使用 GETDATE() 获取当前日期时间，并通过 CAST() 或 CONVERT() 将其转换为纯日期格式。

假设有一个销售表 Sales，包含 DATETIME 类型的 SaleDate 列。

-- 推荐方法：使用范围查询
-- CAST(GETDATE() AS DATE) 获取当天0点
-- DATEADD(day, 1, CAST(GETDATE() AS DATE)) 获取第二天0点
SELECT * FROM Sales
WHERE SaleDate >= CAST(GETDATE() AS DATE) 
  AND SaleDate < DATEADD(day, 1, CAST(GETDATE() AS DATE));

这种方法同样是为了构建一个左闭右开的区间 [当天0点, 第二天0点)，确保查询的准确性和高效性。

主流数据库查询方式对比

为了方便快速查阅,下表小编总结了上述三种数据库查询当天数据的核心方法：

数据库系统	获取当前日期函数	常用查询方式示例 (推荐)
MySQL	CURDATE()	WHERE create_time >= CURDATE() AND create_time < CURDATE() + INTERVAL 1 DAY;
PostgreSQL	CURRENT_DATE	WHERE created_at >= CURRENT_DATE AND created_at < CURRENT_DATE + INTERVAL '1 day';
SQL Server	CAST(GETDATE() AS DATE)	WHERE SaleDate >= CAST(GETDATE() AS DATE) AND SaleDate < DATEADD(day, 1, CAST(GETDATE() AS DATE));

最佳实践与注意事项

1. 索引的重要性：确保用于时间筛选的列（如 create_time, created_at）上已经建立了索引，这是保证大数据量下查询速度的基础。
2. 避免在列上使用函数：如前文反复强调的，在 WHERE 子句中对列使用任何函数（如 DATE(), YEAR(), MONTH() 等）都极有可能导致数据库无法使用该列的索引，从而造成性能瓶颈，始终优先使用范围查询。
3. 时区问题：数据库服务器的时间戳通常以其所在服务器的时区（或UTC）为准，如果你的应用用户遍布全球，需要考虑时区转换，最佳实践是在数据库中统一使用UTC时间存储，在应用层根据用户的时区进行转换和查询。

---

相关问答 (FAQs)

为什么推荐使用 BETWEEN 或者 >= 和 < 的范围查询，而不是直接用 DATE() 函数？

回答： 核心原因在于数据库索引的使用，当在 WHERE 子句中对一个列使用函数时，WHERE DATE(create_time) = '2025-10-27'，数据库必须先对表中该列的每一行数据都执行 DATE() 函数，然后再将结果与给定值进行比较，这个过程使得数据库无法直接利用 create_time 列上已经建立的B-Tree索引，因为它索引的是原始的 DATETIME 值，而不是经过函数处理后的日期值，这最终会导致数据库执行全表扫描，在数据量大的情况下性能会急剧下降，而使用范围查询（如 create_time >= '2025-10-27' AND create_time < '2025-10-28'）则可以直接利用索引进行快速定位，效率高出几个数量级。

如果数据库中的时间戳是UTC时间，但我想按用户所在时区查询“的数据，该怎么办？

回答： 这个问题通常有两种解决方案，第一种，也是更常见和推荐的做法，是在应用层处理，应用服务器获取用户的时区信息（Asia/Shanghai”），然后计算出该时区“所对应的UTC时间范围（上海时区的今天是从UTC时间前一天的16:00到当天的16:00），最后将这个UTC时间范围作为参数传递给数据库进行查询，第二种方案是在数据库层处理，某些数据库（如PostgreSQL）提供了强大的时区转换函数，可以直接在SQL查询中完成。WHERE created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'::date = CURRENT_DATE，虽然可行，但这会增加SQL的复杂性，且可能不如应用层处理灵活，对于大多数系统而言，将时区逻辑放在应用层是更清晰、更易于维护的架构选择。