日期范围查询是SQL中最常见的过滤需求之一，无论做销售报表、用户行为分析还是日志检索，都离不开对日期字段的限定。很多入门教程会直接给出BETWEEN写法，但很少讲清楚这个运算符在日期字段上的边界行为。下面围绕BETWEEN展开，先看基础语法，再深入时间部分和性能细节。

一、BETWEEN在日期字段上的基础语法与闭区间行为

BETWEEN是SQL标准中的范围比较运算符，逻辑上等价于一对大于等于和小于等于条件。当目标字段是DATE类型时，查询某一时间段的数据非常直观。例如订单表orders中order_date为DATE类型，需要统计1月1日到1月31日的订单，可以写成：

SELECT order_id, customer_id, order_date
FROM orders
WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31';

这个条件包含两个端点，等价于 order_date >= '2024-01-01' AND order_date <= '2024-01-31'。因此返回结果包括1月1日当天和1月31日当天。闭区间是BETWEEN的默认语义，这一点与某些编程语言中的范围写法不同，比如Python的range不包含右端点，而SQL中BETWEEN是双闭区间。理解这一点对于避免边界数据丢失或多余至关重要。

如果字段允许NULL，还需要注意BETWEEN不会返回NULL行。当order_date为NULL时，任何与NULL比较的结果都是UNKNOWN，无法满足BETWEEN条件。所以若业务上需要把NULL也纳入统计，应显式加上 OR order_date IS NULL。很多人写日期过滤时忽略了NULL，导致报表总数对不上，排查起来非常耗时。

二、字段带时间部分时的查询陷阱与推荐写法

当日期字段类型从DATE变成DATETIME或TIMESTAMP后，直接使用BETWEEN并且只写日期字符串会引发漏数据。以created_at字段为例，数据类型为DATETIME，想查询整个2024年1月的数据。如果写成：

SELECT *
FROM orders
WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31';

数据库会把字符串'2024-01-31'隐式转换为'2024-01-31 00:00:00'，因此所有1月31日00:00:00之后产生的记录，例如'2024-01-31 14:23:10'，都不满足小于等于这个时间点，会被排除，结果少了一天里的大部分数据。这是日期查询中最常见的错误之一。

更可靠的做法是使用半开区间，即将截止条件写成小于下一天：

SELECT *
FROM orders
WHERE created_at >= '2024-01-01'
  AND created_at < '2024-02-01';

这样无论时间部分是多少，只要属于1月就都能被包含，且不会把2月1日0点的记录误算进来。如果坚持使用BETWEEN并想包含31日全天，也可以写 created_at BETWEEN '2024-01-01 00:00:00' AND '2024-01-31 23:59:59'，但这种方式在时间精度为毫秒或微秒时仍有漏洞，例如'2024-01-31 23:59:59.500'会被漏掉。因此涉及DATETIME、TIMESTAMP或更高精度时间字段时，推荐用半开区间而不是BETWEEN。

另外，在带时间的日期列上直接作范围查询通常可以使用索引，但不要对列包函数，这部分会在下一节展开。这个半开区间的写法在跨数据库时也都适用，是一种更通用的日期过滤习惯。

三、日期范围查询中的索引利用与隐式转换

BETWEEN的底层执行计划通常是一个范围扫描，如果order_date或created_at列上有B-tree索引，查询优化器可以高效定位起始和结束位置。但一旦在列上使用函数，比如 WHERE DATE(created_at) BETWEEN '2024-01-01' AND '2024-01-31'，索引就无法直接匹配，容易退化为全表扫描。不同数据库有不同的处理方式：MySQL 8支持函数索引，可以为DATE(created_at)创建索引；PostgreSQL可以创建表达式索引；SQL Server则可通过计算列或直接对日期范围进行SARGable写法来利用索引。

隐式转换同样会破坏索引或产生意外结果。如果数据库驱动把日期参数当作字符串发送，而字段为DATETIME，通常能隐式转换，但最好在应用层使用明确的日期类型参数。例如Java中通过PreparedStatement的setDate或setTimestamp传入，而不是拼接字符串。示例：

String sql = "SELECT * FROM orders WHERE created_at >= ? AND created_at < ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setTimestamp(1, Timestamp.valueOf("2024-01-01 00:00:00"));
ps.setTimestamp(2, Timestamp.valueOf("2024-02-01 00:00:00"));
ResultSet rs = ps.executeQuery();

参数化查询还能避免SQL注入，当日期来自用户输入时尤其重要。日期格式建议统一使用ISO 8601的YYYY-MM-DD，避免因为数据库本地化设置不同导致解析歧义。同时，使用大于等于加小于的半开区间写法在参数化场景下也更清晰，两个参数分别表示开始和结束，不容易与BETWEEN的闭区间语义混淆。

四、主流数据库的日期字面量与方言差异

虽然BETWEEN在ANSI SQL中标准一致，但不同数据库对日期字面量的处理仍然有差异。MySQL支持直接使用'YYYY-MM-DD'或'YYYYMMDD'字符串与日期类型比较，PostgreSQL推荐使用 DATE '2024-01-01' 这种标准日期常量，SQL Server同样接受'YYYY-MM-DD'，但受语言设置影响时使用'YYYYMMDD'更安全；Oracle则需要使用 TO_DATE('2024-01-01','YYYY-MM-DD') 显式转换。

举例对比PostgreSQL和Oracle写法：

-- PostgreSQL
SELECT * FROM orders WHERE order_date BETWEEN DATE '2024-01-01' AND DATE '2024-01-31';
-- Oracle
SELECT * FROM orders WHERE order_date BETWEEN TO_DATE('2024-01-01','YYYY-MM-DD') AND TO_DATE('2024-01-31','YYYY-MM-DD');

无论哪种数据库，将BETWEEN改写为半开区间都是通用且更稳妥的做法，尤其是当业务需要跨天统计或日期字段包含时间部分时。同时注意时区对TIMESTAMP WITH TIME ZONE的影响，数据库会话时区或服务器时区不一致时，相同的查询可能返回不同结果。存储用户行为时间时建议统一使用UTC，展示层再转换成本地时间，避免范围查询边界因为夏令时或时区偏移产生遗漏或重复。

日期范围查询看起来简单，但BETWEEN的双闭区间、时间部分截断、索引失效和方言差异都可能引入隐蔽错误。掌握半开区间写法、保持列上无函数运算、使用参数化查询，可以在大多数场景下写出正确且高效的SQL。尤其在订单、日志、用户行为等数据量持续增长的表中，这些细节会直接影响查询稳定性和系统负载。