不推荐用 datediff(now(), expire_date) 判断会员过期，应改用 expire_date

如何用 DATEDIFF(NOW(), expire_date) 判断会员是否过期

直接结论：不推荐用 DATEDIFF(NOW(), expire_date) 做过期判断，它容易因日期方向理解错导致逻辑翻转。正确姿势是用 expire_date ——语义清晰、索引友好、无时区歧义。

常见错误现象：DATEDIFF(NOW(), expire_date) 返回正数表示“已过期”，但有人误以为负数才过期；更麻烦的是，当 expire_date 是 DATETIME 类型且含时间（如 '2025-04-01 23:59:59'），NOW() 精确到秒，微小时间差会让结果在临界日反复跳变。

• 始终优先用比较运算符：WHERE expire_date ，一目了然
• 若必须用 DATEDIFF（例如算“还剩几天”），改用 DATEDIFF(expire_date, NOW())：结果为负数即过期，0 表示今天到期，正数表示还有几天
• 确保 expire_date 字段类型是 DATETIME 或 TIMESTAMP，别用 DATE——否则会丢失时间精度，导致凌晨0点就判定过期

为什么 NOW() 在 WHERE 条件里可能让索引失效

NOW() 是非确定性函数，MySQL 8.0 以前无法在索引中预计算，如果写成 WHERE DATEDIFF(NOW(), expire_date) > 0，哪怕 expire_date 有索引，也可能触发全表扫描。

实操建议：

• 把表达式移到右边：WHERE expire_date —— MySQL 能利用 <code>expire_date 索引进行范围查找
• 避免嵌套函数：WHERE DATE(expire_date) 会强制对每行计算 <code>DATE()，索引完全失效
• 如需查“7天内即将过期”的会员，用 WHERE expire_date BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 7 DAY)，仍可走索引

时区问题怎么不踩坑

NOW() 返回的是 MySQL 服务器当前时区的时间，不是客户端时区。如果服务器设为 +00:00（UTC），而业务面向东八区用户，直接比对会导致所有会员提前8小时过期。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

检查与修正方法：

• 查当前会话时区：SELECT @@session.time_zone；查系统时区：SELECT @@global.time_zone
• 统一用 TIMESTAMP 类型存 expire_date：它底层按 UTC 存储，读取时自动转为会话时区，比 DATETIME 更可靠
• 上线前务必确认应用层、数据库、服务器 OS 三者时区一致，或显式指定：SET time_zone = '+08:00'

真实查询示例：查所有已过期会员并标记状态

别写复杂 CASE 套 DATEDIFF，用最简逻辑分层处理：

SELECT 
  id,
  user_id,
  expire_date,
  CASE WHEN expire_date 
<p>注意：<code> 包含“刚好今天过期”的情况；如果业务要求“到期当日仍有效”，就用 <code>，但别写成 <code>——<code>CURDATE()</code> 返回 <code>DATE</code> 类型，隐式转换可能丢精度。</code></code></code></p>
<p>真正难的不是函数怎么写，是搞清业务定义的“过期瞬间”到底指 00:00 还是 23:59，以及这个定义是否和存储字段的类型、时区、索引策略自洽。</p>