使用date()函数会导致索引失效，应改用范围查询；php中需确保datetime对象格式化为’y-m-d h:i:s’再绑定，避免类型不匹配引发截断或错误。
WHERE 里用 DATE() 函数直接截取日期会慢
mysql 中用 DATE(created_at) 做条件，比如 WHERE DATE(created_at) = '2024-05-20'，看着直观，但会导致索引失效——因为对字段加了函数，MySQL 无法走 created_at 上的索引。
- 正确做法是用范围查询：
WHERE created_at >= '2024-05-20 00:00:00' AND created_at - 如果字段是
DATE类型（无时间部分），可直接等值：WHERE created_at = '2024-05-20'，此时索引可用 - PHP 拼接时注意用
date('Y-m-d H:i:s')生成带时分秒的字符串，别漏掉00:00:00和23:59:59这种边界写法（后者不如用“下一天 00:00:00”安全）
PHP 用 strtotime() 处理日期要防空和非法输入
用户传来的日期字符串格式不统一（如 "2024/05/20"、"20-05-2024"、甚至空字符串），strtotime() 遇到解析失败会返回 false，转成 int 就是 0，最终变成 '1970-01-01'——查出完全无关的数据。
- 必须先判断：
if (false === $ts = strtotime($input_date)) { /* 报错或跳过 */ } - 更稳妥用
DateTime::createFromformat()指定格式，例如DateTime::createFromFormat('Y-m-d', $input)，失败返回NULL - 从表单接收后立刻验证并标准化为 Y-m-d 格式再进 SQL，别留着原始字符串一路传
MySQL 的 timestamp 和 DATETIME 在 WHERE 中行为不同
两者都支持标准日期比较，但时区敏感性不同：如果字段是 TIMESTAMP，存入和查询时会自动按 MySQL 服务器时区转换；DATETIME 则原样存储、原样比对。
- 线上环境时区设为
+08:00，但 PHP 脚本里用date_default_timezone_set('Asia/Shanghai')，两者一致才不会“查不到刚插入的数据” - 用
select @@time_zone, @@system_time_zone确认 MySQL 实际时区 - 推荐统一用
DATETIME存储业务时间，避免隐式转换带来的歧义
用 pdo 绑定日期参数时别忘了类型
PDO 默认把所有绑定参数当字符串处理，而 MySQL 对字符串和日期字面量的隐式转换有时不一致（尤其在严格模式下），可能触发警告或意外结果。
立即学习“PHP免费学习笔记（深入）”；
- 显式指定类型：
$stmt->bindValue(':start', $start_date, PDO::PARAM_STR) - 如果变量已是
DateTime对象，调用$dt->format('Y-m-d H:i:s')再绑定，别直接 bindObject - 错误示例：
$stmt->execute([':date' => '2024-05-20'])—— 看似没问题，但万一数据库列是DATE类型，而传入含时间部分的字符串，MySQL 可能截断或报错
事情说清了就结束。日期筛选最常出问题的地方不在语法对不对，而在「PHP 时间对象 → 字符串格式 → MySQL 类型 → 索引是否命中」这一整条链路上的任意一环没对齐。