BETWEEN对DATETIME易漏数据是因为字符串'2024-01-31'隐式转为'2024-01-31 00:00:00'，右边界仅到当日零点；应显式写全时间或改用左闭右开区间。
为什么 BETWEEN 对 DATETIME 容易漏数据
BETWEEN 在 SQL 中是闭区间操作（包含左右边界），但很多人直接写 WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31'，结果发现 2024-01-31 当天 10:30 的记录没被查出来。原因在于：字符串字面量 '2024-01-31' 被隐式转为 DATETIME 时，多数数据库（如 MySQL、SQL Server）会补成 '2024-01-31 00:00:00'，导致右边界实际只到当天零点，而非全天。
- 显式补时间部分最稳妥：用
'2024-01-31 23:59:59'或更精确的'2024-01-31 23:59:59.999'（注意 SQL Server 的毫秒精度是 .997） - 更好做法是改用左闭右开区间：
created_at >= '2024-01-01' AND created_at ，完全避开时间截断问题 - MySQL 8.0+ 支持
TIMESTAMP字面量带时区，但BETWEEN本身不处理时区，务必确认字段和字面量在同一时区上下文
MySQL 中 BETWEEN 遇到 TIMESTAMP 字段的隐式转换陷阱
MySQL 的 TIMESTAMP 类型会自动转为当前会话时区存储/读取，而 BETWEEN 右侧的字符串字面量默认按系统时区解析。例如会话时区是 +08:00，但你写 BETWEEN '2024-01-01' AND '2024-01-01 23:59:59'，MySQL 可能先把右边转成 UTC 再比对，导致逻辑错位。
- 查当前会话时区：
SELECT @@time_zone - 强制统一时区比较：
WHERE CONVERT_TZ(created_at, '+00:00', '+08:00') BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59'（不推荐，性能差） - 更可靠：把字段和字面量都转成 UTC 比较，或统一用
DATETIME类型存数据（不自动时区转换）
PostgreSQL 中 BETWEEN 处理 TIMESTAMP WITH TIME ZONE 的注意事项
PostgreSQL 的 TIMESTAMP WITH TIME ZONE（TIMESTAMPTZ）在比较时会自动归一化到 UTC，但 BETWEEN 的字面量如果没有时区信息，会被当作本地时区处理——这和你的 timezone 参数强相关。
- 查当前时区：
SHOW timezone - 安全写法：所有字面量显式带时区，例如
BETWEEN '2024-01-01 00:00:00+08' AND '2024-01-31 23:59:59+08' - 或者统一转成 UTC：
BETWEEN '2024-01-01'::timestamptz AT TIME ZONE 'UTC' AND '2024-01-31 23:59:59'::timestamptz AT TIME ZONE 'UTC' - 注意：索引能否生效取决于表达式是否可下推，带
AT TIME ZONE的写法可能使索引失效
用 BETWEEN 做范围查询时索引是否有效
只要 BETWEEN 两侧都是常量或绑定参数（非函数包裹字段），且字段上有索引，BETWEEN 就能走索引。但常见破坏索引的行为包括：
- 对字段用函数：
WHERE DATE(created_at) BETWEEN '2024-01-01' AND '2024-01-31'→ 全表扫描 - 字段参与计算：
WHERE created_at + INTERVAL '1 day' BETWEEN ...→ 索引失效 - 混合类型隐式转换：
WHERE created_at BETWEEN '2024-01-01' AND 1672531199（后者是 Unix 时间戳）→ 类型不匹配，可能放弃索引 - 建议用
EXPLAIN（MySQL/PostgreSQL）或SET SHOWPLAN_ALL ON（SQL Server）验证执行计划
真正麻烦的不是语法对不对，而是时间精度、时区、隐式转换、索引这四层嵌套在一起时，单靠 BETWEEN 很难兼顾准确性和性能。宁可用两个明确的 >= 和 来控制边界，尤其在跨天、跨月、跨年场景下。
