MySQL的Between And操作符在包含边界值时为什么容易出错？

MySQL的BETWEEN AND包含边界值，出错主因是DATE/DATETIME隐式补全、TIMESTAMP时区偏移、NULL三值逻辑、类型不匹配及函数导致索引失效；推荐用>= + <开区间写法。

MySQL 的 BETWEEN AND 确实包含边界值，但出错几乎从不因为“它不包含”，而是因为边界值被悄悄改写了。

DATE vs DATETIME/TIMESTAMP 的隐式截断行为

当你写 WHERE create_time BETWEEN '2024-01-01' AND '2024-01-31'，MySQL 会按字段类型自动补全时间部分：

• 如果 create_time 是 DATE 类型：两边都当作完整日期处理，'2024-01-31' 就是 '2024-01-31'，能匹配所有该日记录；
• 如果 create_time 是 DATETIME 或 TIMESTAMP：左侧变成 '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，读取时再按会话时区转换。若你用 BETWEEN '2024-01-01' AND '2024-01-31' 查询，而当前 time_zone = '+08:00'，那实际比较的是 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 能绕过所有上述陷阱：

• 右边界用下月第一天，天然避免时间部分歧义；
• 不依赖字符串隐式转换，类型对齐清晰；
• 优化器更容易下推索引范围，执行计划更稳定；
• 即使字段是 TIMESTAMP，只要时区一致， 仍表示“严格小于该日零点”，语义明确。

真正容易被忽略的，不是“要不要用 BETWEEN”，而是“你写的字符串，在 MySQL 解析后，到底变成了什么时间值”。