数据库查询timestamp超30天数据异常：结果含不足30天数据

这问题我之前处理过好几次，大概率是时间逻辑或者时区的坑在作怪！结合你的场景，我整理几个最可能的遗漏点：

1. 时间筛选的逻辑方向搞反了 #

这是最容易犯的低级错误！你说要找“30天后删除”的旧数据（也就是超过30天的历史数据），但如果你的SQL写的是WHERE time > 30天前的时间，那其实查的是最近30天内的新数据，正好和需求相反！

正确的逻辑应该是：筛选那些时间早于等于30天前的数据，比如：

-- MySQL示例：用UTC时间避免时区问题
SELECT * FROM your_table WHERE time <= DATE_SUB(UTC_TIMESTAMP(), INTERVAL 30 DAY);

-- PostgreSQL示例
SELECT * FROM your_table WHERE time <= CURRENT_TIMESTAMP - INTERVAL '30 days';

2. 时区不匹配导致时间偏差 #

如果你的数据库时区和cronjob运行的服务器时区不一样（比如数据库用UTC，服务器用北京时间），那两边计算的“30天前”时间就会差好几个小时，结果自然会混进不符合要求的数据。

解决办法：

• 统一所有环境的时区（推荐用UTC，避免夏令时等坑）；
• 直接用数据库的内置时间函数计算，不要在应用层计算后传入参数，比如上面示例里的UTC_TIMESTAMP()、CURRENT_TIMESTAMP都是数据库自己的时间，能保证和存储的time字段时区一致。

3. cronjob脚本里的时间计算错误 #

如果你的cronjob脚本是先在代码里计算30天前的时间，再拼到SQL里，那要检查代码的时间处理逻辑：

• 是不是用了本地时间而非UTC？比如Python里用datetime.now()而不是datetime.utcnow()；
• 时间格式转换有没有问题？比如把datetime转成字符串时，时区信息丢失了，导致数据库解析错误。

4. Timestamp类型的存储细节 #

如果你的time字段是带时区的类型（比如PostgreSQL的TIMESTAMP WITH TIME ZONE），但存储时没有正确转换时区，或者查询时没有指定时区，也会导致筛选结果异常。这种情况建议直接用数据库的时区函数来做计算，确保和存储的时间戳时区一致。

快速排查步骤 #

1. 手动执行你cronjob里的SQL语句，看返回结果是否和预期一致——如果手动执行也有问题，那就是SQL本身的逻辑错了；
2. 挑一条不符合预期的数据，查看它的time字段值，和你计算的“30天前”时间点做对比，看哪个环节的时间计算出了问题；
3. 检查数据库和cronjob服务器的系统时区，用SELECT @@time_zone;（MySQL）或SHOW TIME ZONE;（PostgreSQL）确认数据库时区。

内容的提问来源于stack exchange，提问作者Jack The Baker