错误根源在于日期查询逻辑误用：WHERE created_at > NOW() 会因NOW()含时分秒导致范围不准确，正确做法是明确边界如created_at >= '2026-07-30 00:00:00' AND created_at < '2026-07-31 00:00:00'。
SELECT WHERE 日期条件写成 > NOW() 就会错
这不是 bug，是逻辑误用。比如想查“今天之后的数据”，写 where created_at > now()，结果把“今天下午三点”和“明天早上八点”全捞出来——你真正要的其实是“从今天零点开始”的范围。
常见错误现象：页面显示“今日订单”，导出却包含明天的记录；或者搜索“2026-07-30”，结果里混进 2026-07-31 的数据。
- 用
>或<比较时间字段时，必须明确边界：比如查“今天及以后”，应写WHERE created_at >= '2026-07-30 00:00:00'，而不是依赖NOW() -
NOW()带时分秒，每次执行值都不同，不适合做静态日期筛选；若真要用，配合DATE(NOW())截断时间部分：WHERE DATE(created_at) = DATE(NOW()) - 但注意：
DATE(created_at)会让created_at字段索引失效，大数据量时变慢；更优写法是WHERE created_at >= '2026-07-30' AND created_at < '2026-07-31'
DATETIME 和 TIMESTAMP 对时区响应完全不同
phpMyAdmin 显示的日期值是否“准确”，取决于字段类型和 MySQL 当前时区设置，不是界面能改的。
如果你看到的时间比预期快/慢 8 小时，大概率不是 phpMyAdmin 问题，而是字段类型 + 时区组合导致的隐式转换。
-
DATETIME：存什么显示什么，完全不涉及时区。设成'2026-07-30 10:00:00'，无论 MySQL 时区是+00:00还是Asia/Shanghai，phpMyAdmin 都原样显示 -
TIMESTAMP：存入时自动转为 UTC，读取时按当前会话时区（@@session.time_zone）转回。如果之前在 UTC 时区插入，现在会话是+08:00，就会多显示 8 小时 - 查当前会话时区：
SELECT @@session.time_zone;；查全局时区：SELECT @@global.time_zone; - 临时修复（仅当前连接有效）：
SET time_zone = '+08:00';，但生产环境应写入 MySQL 配置文件并重启
导出 CSV 里的日期和界面上看到的不一致
不是编码或格式问题，是导出时没复用界面查询的 ORDER BY 或漏掉了日期范围条件。
立即学习“PHP免费学习笔记（深入）”；
典型表现：界面上按 created_at DESC 排好序，导出 CSV 却乱序；或者界面上只显示 2026-07-30 的数据，导出里却有 2026-07-29 的记录。
- 导出 SQL 必须显式包含
ORDER BY，数据库不保证无序查询的返回顺序 - 检查导出逻辑是否删掉了界面用的
LIMIT和OFFSET—— 导出需要全量，不能带分页参数 - 确认导出用的 WHERE 条件和界面完全一致：比如界面用
WHERE DATE(created_at) = '2026-07-30'，导出不能简化为WHERE created_at >= '2026-07-30'（后者会漏掉时间部分） - 避免在 PHP 层对导出结果二次排序，前后端排序规则稍有差异就会导致顺序漂移
phpMyAdmin 界面里输入日期筛选框没反应
这是 phpMyAdmin 的“快速搜索”功能限制，它对日期字段默认走字符串模糊匹配，不是结构化查询。
比如你在“查找”框里输 2026-07-30，实际执行的是类似 WHERE created_at LIKE '%2026-07-30%'，对 DATETIME 字段可能命中，但对 TIMESTAMP 或带毫秒的值就失效。
- 可靠做法：切到 SQL 标签页，手写精确查询，例如：
SELECT * FROM orders WHERE created_at >= '2026-07-30 00:00:00' AND created_at < '2026-07-31 00:00:00'; - 不要依赖 phpMyAdmin 表格上方的“搜索”输入框处理日期，它不解析日期语义，也不校验格式合法性
- 如果字段是
INT存 Unix 时间戳（如1722326400），搜索框输日期字符串根本不会匹配，必须换算成数字再查
时区、字段类型、SQL 边界写法、导出路径——这四个点只要一个没对齐，日期查询结果就会“看起来不准”。最麻烦的是它们彼此耦合，改了 MySQL 时区可能让 Laravel 时间解析崩掉，而换了 DATETIME 字段又得重跑历史数据转换。动手前先用 SELECT @@session.time_zone, @@global.time_zone; 和 SHOW CREATE TABLE your_table; 把底细摸清。
