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 解析后，到底变成了什么时间值”。
