ThinkPHP 的 whereBetween 对字符串时间字段无效，因数据库按字典序而非时间语义比较；应优先改字段为 DATETIME 类型，否则用 whereRaw + STR_TO_DATE 实现安全范围查询。
ThinkPHP 的 whereBetween 对字符串时间字段无效
直接对 created_at 这类存为 'Y-m-d H:i:s' 字符串的字段用 whereBetween，查出来的结果常少几条——因为数据库按字典序比较字符串，不是按时间语义。比如 '2024-01-01 10:00:00' 和 '2024-01-01 9:59:59'，后者字符串比前者小，但时间上却更早。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认字段类型：用
SHOW COLUMNS FROM table_name LIKE 'created_at'查看是否真是VARCHAR或TEXT，而非DATETIME - 优先改表结构：执行
ALTER TABLE table_name MODIFY created_at DATETIME，再用原生whereBetween最省心 - 若无法改库，必须用字符串字段，则别用
whereBetween，改用whereRaw手动转时间比较
用 whereRaw 实现字符串时间范围查询（MySQL）
MySQL 支持 STR_TO_DATE 把字符串转成时间类型再比较，这是最稳的兜底方案。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确保字符串格式统一且可被解析，例如全是
'Y-m-d H:i:s'；含毫秒、时区或空格不一致会返回NULL，导致条件失效 - 写法示例：
$model->whereRaw("STR_TO_DATE(created_at, '%Y-%m-%d %H:%i:%s') BETWEEN ? AND ?", [$start, $end]) - 注意参数顺序：两个
?分别对应$start和$end，值必须是格式匹配的字符串，如'2024-01-01 00:00:00' - 性能影响：该字段无法走索引，大数据量时会全表扫描；如有高频查询，务必加函数索引（MySQL 8.0+）：
CREATE INDEX idx_created_at_time ON table_name (STR_TO_DATE(created_at, '%Y-%m-%d %H:%i:%s'))
ThinkPHP 6/7 中 whereTime 不适用于字符串字段
whereTime 看似能处理时间，但它底层仍依赖字段是时间类型；对字符串字段调用 whereTime('created_at', 'between', [$start, $end])，TP 会直接拼成字符串比较，结果不可靠。
常见错误现象：
- 查
2024-01-01到2024-01-31，漏掉'2024-01-05 15:30:00'（因字符串比较时'2024-01-05 15:30:00' < '2024-01-31'不成立） - 日志里看到生成的 SQL 是
WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31'，没转函数，纯字符串截断比较 - TP 版本差异：6.x 和 7.x 行为一致，都**不自动识别字符串时间字段**，别指望升级解决
边界值处理：开闭区间与字符串精度
字符串时间的边界容易多查或少查 1 秒，尤其当原始数据带毫秒或时区时。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 统一用
Y-m-d H:i:s截断再比较，避免毫秒干扰：用 PHP 的date('Y-m-d H:i:s', strtotime($time))标准化输入 - 若需左闭右开（如统计「当天」不含下一秒），别写
BETWEEN，改用：$model->whereRaw("STR_TO_DATE(created_at, '%Y-%m-%d %H:%i:%s') >= ? AND STR_TO_DATE(created_at, '%Y-%m-%d %H:%i:%s') < ?", [$start, $end]) - 注意 MySQL 的
STR_TO_DATE对非法格式静默返回NULL，可在查询前加WHERE created_at REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}$'过滤脏数据
