mysql中between对datetime/timestamp字段存在隐式类型转换问题：字符串右边界被截为'2023-12-31 00:00:00'，漏掉当日后续时间数据；date类型无此问题；推荐显式补全时间或改用>= and
MySQL中BETWEEN对日期字段的隐式类型转换问题
直接用 BETWEEN '2023-01-01' AND '2023-12-31' 查询 DATETIME 或 TIMESTAMP 字段时，MySQL 会把字符串当作 DATE 类型处理，导致右边界被截断为 '2023-12-31 00:00:00'，漏掉当天 00:00:01 之后的所有记录。
这不是 bug，是 MySQL 的类型优先级规则：当字符串与时间类型比较时，会尝试按最宽松方式转换，而 BETWEEN 是闭区间，'2023-12-31' 不等于 '2023-12-31 23:59:59'。
- 若字段是
DATE类型（只存年月日），BETWEEN '2023-01-01' AND '2023-12-31'安全可用 - 若字段是
DATETIME或TIMESTAMP，必须显式补全时间部分，或改用>= AND - 避免依赖隐式转换——不同 MySQL 版本或 SQL mode 下行为可能不一致
STR_TO_DATE不是万能的，用错场景反而引入错误
STR_TO_DATE() 只在输入是「非标准格式字符串」时才需要，比如 '01/15/2023'、'15-Jan-2023'。如果原始数据已经是 '2023-01-15' 这类 ISO 格式，再套一层 STR_TO_DATE('2023-01-15', '%Y-%m-%d') 属于冗余操作，且容易因格式符写错引发空值（NULL）。
常见误用：
- 把
STR_TO_DATE('2023-01-01', '%Y-%m-%d')当作“保险转换”，实际它和直接写'2023-01-01'在语义上等价，但多一次函数调用开销 - 格式符不匹配：如用
'%Y/%m/%d'解析'2023-01-01'，结果为NULL，导致查询无声失败 - 在 WHERE 条件中对字段使用
STR_TO_DATE(created_at, '%Y-%m-%d')—— 这会让索引失效，哪怕created_at有索引
安全查日期范围的两种推荐写法
核心原则：让字段本身参与比较，避免对字段做函数处理；边界值按字段类型精确构造。
假设表 orders 有 created_at DATETIME 字段，要查 2023 年全年订单：
- ✅ 推荐写法 1（显式时间边界，走索引）：
WHERE created_at >= '2023-01-01 00:00:00' AND created_at
- ✅ 推荐写法 2（用 DATE() 提取日期部分，仅当确实只需按日聚合）：
WHERE DATE(created_at) BETWEEN '2023-01-01' AND '2023-12-31'
⚠️ 注意：DATE()会使索引失效，适合数据量小或配合覆盖索引的场景 - ❌ 避免写法：
WHERE created_at BETWEEN '2023-01-01' AND '2023-12-31'（漏掉 12-31 全天大部分数据）
遇到字符串日期字段怎么办？先确认存储格式再决定是否用STR_TO_DATE
如果字段类型是 VARCHAR，且内容形如 '2023/01/15 14:30:22' 或 '15-01-2023'，才需要 STR_TO_DATE() 转换。但务必验证转换结果是否有效：
- 先试运行：
SELECT STR_TO_DATE('2023/01/15', '%Y/%m/%d');看是否返回正确DATETIME - 检查是否有脏数据导致转换失败：
SELECT * FROM logs WHERE STR_TO_DATE(date_str, '%d-%m-%Y') IS NULL; - 转换后立即比较，不要存回字符串字段：
WHERE STR_TO_DATE(date_str, '%Y-%m-%d') BETWEEN '2023-01-01' AND '2023-12-31' - 长期方案：把这类字段改成
DATE或DATETIME类型，避免每次查询都解析
日期范围查询真正难的不是语法，而是搞清字段类型、数据实际格式、以及 MySQL 如何做类型推导。很多“查不到”的问题，根源都在把 '2023-12-31' 当成了全天，而 MySQL 默认只认成零点。
