先说结论：MySQL 的 BETWEEN AND 确实包含边界值，但出错几乎从不因为“它不包含”，而是因为边界值被悄无声息地改写了。
这条 SQL 看起来再自然不过：WHERE create_time BETWEEN '2024-01-01' AND '2024-01-31'。但实际跑出来的结果，很可能会漏掉当月最后一天的数据。问题究竟出在哪里？
你写的是日期字符串，MySQL 读到的是字段类型，这中间隐藏着一整套隐式转换规则——而它们并不总是按照人们的直觉去工作。
DATE vs DATETIME/TIMESTAMP 的隐式截断行为
当字段是 DATE 类型时，两边都当作完整日期处理，'2024-01-31' 就是 '2024-01-31'，能命中所有该日记录，没有任何问题。
可一旦字段是 DATETIME 或 TIMESTAMP，MySQL 就会“好心”地自动补全时间部分——左侧变成 '2024-01-01 00:00:00'，右侧变成 '2024-01-31 00:00:00'。结果立刻浮出水面：'2024-01-31 00:00:01' 到 '2024-01-31 23:59:59' 的全部数据，被干干净净地漏掉了。
这压根不是 BETWEEN 的 bug，而是字符串到时间类型的隐式转换规则在起作用。理解了这个，就抓住了许多按月统计报表“对不上账”的根源所在。
时区对 TIMESTAMP 字段的边界偏移
TIMESTAMP 值在存储时转为 UTC，读取时再按会话时区转换。如果当前时区是 '+08:00'，用 BETWEEN '2024-01-01' AND '2024-01-31' 查询时，实际比较的其实是 UTC 时间 '2023-12-31 16:00:00' 到 '2024-01-31 16:00:00'——整个区间向左平移了 8 小时。这可不是小误差，它会让你的报表日期线变得难以置信。
应对方法其实不复杂：查一下 SELECT @@time_zone 确认当前时区设置；要么统一用 DATETIME 存储本地时间（推荐）；要么显式使用 CONVERT_TZ() 转换边界值，比如 CONVERT_TZ('2024-01-31', '+08:00', '+00:00')。
NULL 和类型不一致导致的逻辑静默失效
BETWEEN 遇到 NULL 时返回 NULL，整行被过滤——这就是三值逻辑的陷阱。不是报错，不是跳过，而是安静地消失。这会让含空值的字段“查不到但不知道原因”，调试起来特别棘手。
还有几个常见的坑值得留意：
- 用字符串
'100'去比数值列amount（DECIMAL），可能触发隐式转换，丢失精度或引发全表扫描； - 边界值顺序写反，比如
BETWEEN '2024-12-31' AND '2024-01-01'，结果恒为空——优化器并不会帮你交换顺序； - 对字段加函数，比如
DATE(create_time) BETWEEN ...，直接让索引失效，执行计划瞬间“降级”。
为什么开区间写法（>= + <）是更稳妥的选择
用 WHERE create_time >= '2024-01-01' AND create_time < '2024-02-01' 能一次性绕开上述所有陷阱：
- 右边界用下月第一天，天然避免了时间部分的歧义；
- 不依赖字符串隐式转换，类型对齐清晰；
- 优化器更容易下推索引范围，执行计划更稳定；
- 即使字段是
TIMESTAMP，只要时区一致，< '2024-02-01'表示“严格小于该日零点”，语义毫无歧义。
回过头来看，真正容易被忽略的，不是“要不要用 BETWEEN”，而是“你写的字符串，在 MySQL 解析后，到底变成了什么时间值”。这个问题想通了，日后的查漏补缺工作就能轻松不少。
