不推荐用 DATEDIFF(NOW(), expire_date) 判断会员过期，应改用 expire_date < NOW()——语义清晰、索引友好、无时区歧义；若需计算剩余天数，用 DATEDIFF(expire_date, NOW())。
如何用 DATEDIFF(NOW(), expire_date) 判断会员是否过期
直接结论：不推荐用 DATEDIFF(NOW(), expire_date) 做过期判断，它容易因日期方向理解错导致逻辑翻转。正确姿势是用 expire_date < NOW()——语义清晰、索引友好、无时区歧义。
常见错误现象：DATEDIFF(NOW(), expire_date) 返回正数表示“已过期”，但有人误以为负数才过期；更麻烦的是，当 expire_date 是 DATETIME 类型且含时间（如 '2025-04-01 23:59:59'），NOW() 精确到秒，微小时间差会让结果在临界日反复跳变。
- 始终优先用比较运算符：
WHERE expire_date < NOW()，一目了然 - 若必须用
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 < NOW()—— MySQL 能利用expire_date索引进行范围查找 - 避免嵌套函数：
WHERE DATE(expire_date) < CURDATE()会强制对每行计算DATE()，索引完全失效 - 如需查“7天内即将过期”的会员，用
WHERE expire_date BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 7 DAY)，仍可走索引
时区问题怎么不踩坑
NOW() 返回的是 MySQL 服务器当前时区的时间，不是客户端时区。如果服务器设为 +00:00（UTC），而业务面向东八区用户，直接比对会导致所有会员提前8小时过期。
检查与修正方法：
- 查当前会话时区：
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 < NOW() THEN 'expired' ELSE 'active' END AS status FROM members WHERE expire_date <= NOW();
注意：<= NOW() 包含“刚好今天过期”的情况；如果业务要求“到期当日仍有效”，就用 < DATE_ADD(NOW(), INTERVAL 1 DAY)，但别写成 < CURDATE() + INTERVAL 1 DAY——CURDATE() 返回 DATE 类型，隐式转换可能丢精度。
真正难的不是函数怎么写，是搞清业务定义的“过期瞬间”到底指 00:00 还是 23:59，以及这个定义是否和存储字段的类型、时区、索引策略自洽。
