MySQL中DATE_ADD与NOW()比较无结果问题求助

我来帮你搞定这个问题，这种情况大概率是数据类型不匹配或者比较逻辑的小疏漏导致的，咱们一步步拆解解决：

一、先确认数据类型与实际值 #

首先得排查核心的类型问题：你的time_created字段是不是DATETIME类型？locked_time是不是整数类型（比如INT）？如果time_created是DATE类型，那DATE_ADD生成的until会不带时分秒，和带完整时间的NOW()比较就会出问题。

你可以先执行这条语句，直观看到所有关键值和比较结果：

SELECT 
  `time_created`,
  `locked_time`,
  DATE_ADD(`time_created`, INTERVAL `locked_time` DAY) AS `until`,
  NOW(),
  -- 直接输出比较的布尔结果
  DATE_ADD(`time_created`, INTERVAL `locked_time` DAY) >= NOW() AS is_still_locked
FROM `' . DATABASE_PREFIX . 'users_locked` 
WHERE `user_id`=:user_id 
LIMIT 1;

通过这个结果，你能立刻判断是值的问题，还是类型转换的问题。

二、优化比较逻辑的写法 #

直接在WHERE里用计算后的临时字段比较，容易触发隐式类型转换，甚至没法利用索引。推荐两种更稳妥的写法：

方案1：反向计算时间差（推荐） #

不用生成until字段，直接计算当前时间和time_created的间隔，和锁定天数对比：

SELECT *
FROM `' . DATABASE_PREFIX . 'users_locked` 
WHERE 
  `user_id`=:user_id 
  -- 判断当前时间是否还在锁定有效期内
  AND TIMESTAMPDIFF(SECOND, `time_created`, NOW()) <= (`locked_time` * 86400)
LIMIT 1;

这里用秒数计算更精准（一天=86400秒），避免了天级别的精度误差（比如锁定1天，刚好24小时整才过期）。

方案2：确保类型一致的直接比较 #

如果一定要保留until字段的计算，可以强制统一类型，或者用CURRENT_TIMESTAMP()替代NOW()（兼容性更好）：

SELECT *, DATE_ADD(`time_created`, INTERVAL `locked_time` DAY) AS `until`
FROM `' . DATABASE_PREFIX . 'users_locked` 
WHERE 
  `user_id`=:user_id 
  AND DATE_ADD(`time_created`, INTERVAL `locked_time` DAY) >= CAST(NOW() AS DATETIME)
LIMIT 1;

三、排查时区不一致问题 #

这是很容易忽略的坑：MySQL服务器的时区和你应用程序的时区不一样！比如应用用东八区，但MySQL用UTC，那NOW()返回的时间会比你预期的until早/晚8小时，导致比较结果完全不符合预期。

你可以执行SELECT @@time_zone;查看MySQL时区，再和应用时区对比。如果不一致，要么修改MySQL时区配置，要么在查询中指定时区：

SELECT *, DATE_ADD(`time_created`, INTERVAL `locked_time` DAY) AS `until`
FROM `' . DATABASE_PREFIX . 'users_locked` 
WHERE 
  `user_id`=:user_id 
  AND DATE_ADD(`time_created`, INTERVAL `locked_time` DAY) >= CONVERT_TZ(NOW(), @@session.time_zone, '+08:00')
LIMIT 1;

把+08:00换成你的应用时区即可。

四、最后确认数据存在性 #

别忘记检查这条user_id的记录是否真的在users_locked表里！有时候可能是参数传错了，导致根本没查到数据，误以为是比较逻辑的问题。

内容的提问来源于stack exchange，提问作者Adrian Preuss