between时间范围易漏数据，因隐式补零致右边界截断；应显式写全时间或用>=与= '2023-01-01' and created_at

WHERE子句里用BETWEEN写时间范围，但结果不对？

直接用 BETWEEN '2023-01-01' AND '2023-12-31' 看似简洁，但容易漏掉当天的全部数据——因为默认会截断为 '2023-12-31 00:00:00'，而你表里的 created_at 可能是 '2023-12-31 14:22:05'，它不满足“小于等于”条件。

根本原因是 BETWEEN 是闭区间（包含两端），但时间字段常带时分秒，只写日期字符串会隐式补零，导致右边界被砍掉一整天。

• ✅ 正确做法：显式写出完整时间边界，比如 BETWEEN '2023-01-01 00:00:00' AND '2023-12-31 23:59:59'
• ⚠️ 更稳妥写法（推荐）：改用 >= AND ，例如 <code>created_at >= '2023-01-01' AND created_at —— 这样既避免秒级精度问题，又天然兼容 <code>TIMESTAMP 和 DATETIME 类型
• ❌ 避免对 DATE 类型字段用 BETWEEN 混合字符串，比如 date_col BETWEEN '2023-01-01' AND '2023-12-31' 在某些数据库（如 PostgreSQL）中可能因时区或隐式转换出错

PostgreSQL里BETWEEN对timestamptz字段特别容易翻车

PostgreSQL 的 timestamptz 会自动按会话时区做转换，而 BETWEEN 两边字符串如果没有时区标识，会被当作本地时间解析，导致跨时区查询结果漂移。

• ✅ 写死时区：用 BETWEEN '2023-01-01 00:00:00+08' AND '2023-12-31 23:59:59+08'
• ✅ 更可靠：统一转为 UTC 比较，比如 created_at AT TIME ZONE 'UTC' BETWEEN '2023-01-01' AND '2023-12-31'
• ⚠️ 不要依赖 CURRENT_DATE 直接塞进 BETWEEN——它返回的是日期类型，和 timestamptz 比较时会触发隐式 cast，行为不可控

MySQL 8.0+ 中BETWEEN配合索引失效的典型场景

即使你在 created_at 上建了索引，BETWEEN 也可能让优化器放弃使用索引，尤其当右边值是函数或表达式时。

• ❌ 错误示例：created_at BETWEEN '2023-01-01' AND DATE_ADD(NOW(), INTERVAL -1 DAY) —— DATE_ADD 是运行时计算，MySQL 无法预估范围，常退化为全表扫描
• ✅ 改成字面量或参数：created_at BETWEEN ? AND ?（应用层算好两个时间戳传入）
• ✅ 或改用确定性函数：created_at >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) AND created_at ，这种写法在 MySQL 8.0+ 中能更好利用索引

用BETWEEN查“最近7天”时，别忽略边界当天的0点问题

很多人写 BETWEEN DATE_SUB(NOW(), INTERVAL 6 DAY) AND NOW()，本意是查最近7个自然日，但实际查的是从“6天前此刻”到“现在”，跨度其实是168小时，不是7个完整的日历日。

• ✅ 查完整日历日（比如今天是 2024-04-05，要查 2024-03-30 到 2024-04-05）：DATE(created_at) BETWEEN '2024-03-30' AND '2024-04-05'
• ⚠️ 但注意：DATE(created_at) 会导致索引失效，除非你建了函数索引（MySQL 8.0+/PostgreSQL）
• ✅ 推荐替代：created_at >= '2024-03-30' AND created_at —— 简洁、可索引、无歧义

时间范围过滤真正麻烦的从来不是语法，而是你没意识到数据库怎么解释那个“2023-12-31”——它到底代表一整天，还是一个瞬间。