MySQL中BETWEEN对日期是闭区间，但DATETIME字段易因隐式转换漏数据；应显式指定时间部分如'2024-01-01 00:00:00'到'2024-01-31 23:59:59'，或用>=与
MySQL中BETWEEN对日期的边界处理是包含两端的，但容易因隐式类型转换出错
BETWEEN在MySQL里确实是闭区间（包含min和max），但问题常出在你传入的日期值没带时间部分，而字段是DATETIME或TIMESTAMP类型。比如查询'2024-01-01'到'2024-01-31'，实际会匹配到'2024-01-31 00:00:00'，却漏掉当天其他时间点的数据。
用CAST或STR_TO_DATE显式控制时间精度
别依赖字符串自动转换。把边界转成明确的DATETIME值，再手动补全时间部分：
- 查“2024-01-01全天”到“2024-01-31全天”，写成：
WHERE create_time BETWEEN '2024-01-01 00:00:00' AND '2024-01-31 23:59:59'
- 更安全的做法是用开区间+
避免秒级截断：<br><pre class="brush:php;toolbar:false;">'2024-02-01'</pre> - 如果参数来自用户输入且只有日期格式，用
STR_TO_DATE('2024-01-01', '%Y-%m-%d')确保被当日期解析，而非字符串比较
BETWEEN在TIMESTAMP字段上受时区影响，必须确认会话时区
MySQL的TIMESTAMP存的是UTC，读取时按time_zone变量转换。如果你用BETWEEN '2024-01-01' AND '2024-01-31'，而会话时区是+08:00，那实际比较的是UTC时间2023-12-31 16:00:00到2024-01-31 16:00:00——结果完全偏移。
- 执行前先查
SELECT @@time_zone，必要时用SET time_zone = '+00:00'临时切到UTC - 或者统一用
CONVERT_TZ()把边界转到存储时区：WHERE create_time BETWEEN CONVERT_TZ('2024-01-01', '+08:00', '+00:00') AND CONVERT_TZ('2024-01-31 23:59:59', '+08:00', '+00:00') - 更推荐：字段用
DATETIME类型存本地时间，避开时区自动转换
索引失效风险：函数包裹边界或字段会导致range扫描退化为index或ALL
别这么写：WHERE DATE(create_time) BETWEEN '2024-01-01' AND '2024-01-31'——DATE()会让create_time索引失效。
- 确保
BETWEEN左侧是纯列名，右侧是常量表达式 - 如果必须按日统计，用
GROUP BY DATE(create_time)，但查询条件仍走原字段范围 - 对高频日期查询，可考虑加生成列+索引：
ALTER TABLE orders ADD COLUMN create_date DATE AS (DATE(create_time)) STORED;<br>CREATE INDEX idx_create_date ON orders(create_date);
日期范围查询真正麻烦的不是语法，而是你默认认为“字符串日期就等于那天零点”这个假设——MySQL不认这个，它只认字面值和类型转换规则。边界、时区、索引三者只要漏一个，结果就可能少数据或多数据，而且很难一眼看出来。
