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 很难兼顾准确性和性能。宁可用两个明确的 >= 和 来控制边界，尤其在跨天、跨月、跨年场景下。