倒计时必须用 NOW() 而非 SYSDATE()，因其在事务中时间恒定；服务器须启用 NTP 同步；end_time 应存 UTC 的 DATETIME 类型，避免 TIMESTAMP 自动时区转换。
MySQL 里用 NOW() 还是 SYSDATE() 做倒计时？
倒计时依赖的是「当前时间」，但 MySQL 有两个看似一样的函数： NOW() 和 SYSDATE()。它们在事务中行为不同——NOW() 返回语句开始执行的时间点（事务内恒定），而 SYSDATE() 每次调用都返回实时系统时间。做活动倒计时（比如 end_time - NOW()）必须用 NOW()，否则同一事务里多次计算会漂移，前端看到的剩余时间可能越刷越短。
- 场景：活动页 SQL 查询倒计时字段，如
SELECT end_time - NOW() AS remaining FROM activities WHERE id = 123 - 别用
SYSDATE()：它在存储过程或长事务里会“跳变”，导致同一请求里两次SELECT算出不同结果 - 注意时区：
NOW()返回的是 MySQL 服务器设置的时区时间，不是 UTC，也不是客户端本地时间
MySQL 服务器时间不准，倒计时就全错
MySQL 自己不维护时间，完全依赖操作系统时钟。如果服务器没开 NTP 同步，跑几天就差几十秒，活动提前结束或延迟关闭都是真实发生过的事故。
- 检查命令：
timedatectl status（Linux），确认System clock synchronized: yes - MySQL 无法自动校时，
SET TIMESTAMP只影响单个会话，不能修复根本问题 - 不要在应用层“手动加偏移”来对齐时间——一旦服务器重启或 NTP 恢复，偏移逻辑反而制造更大误差
- 生产环境必须配置
chronyd或ntpd，并设为开机自启；Docker 容器需挂载宿主机时间（/etc/localtime）且宿主机本身已同步
跨时区用户看到的倒计时怎么统一？
MySQL 存的 end_time 是什么时区，决定了所有计算基准。推荐统一存 UTC 时间，而不是服务器本地时间。
- 建表时用
DATETIME（非TIMESTAMP），值存 UTC，例如插入'2024-06-01 16:00:00'表示 UTC 时间 - 查询时用
DATE_ADD(NOW(), INTERVAL TIME_TO_SEC(TIMEDIFF(NOW(), UTC_TIMESTAMP())) HOUR_SECOND)这类换算极不可靠，别这么干 - 正确做法：应用层读出 UTC 的
end_time，由前端或后端按用户所在时区转换显示；MySQL 只负责“UTC 到期判断” - 如果硬要用 MySQL 做时区转换，至少用
CONVERT_TZ(end_time, '+00:00', '+08:00')，但要注意 MySQL 时区表是否加载（mysql_tzinfo_to_sql是否执行过）
为什么用 TIMESTAMP 字段存倒计时终点很危险？
TIMESTAMP 类型会自动转成服务器时区存储、再转回 UTC 查询，表面省事，实则埋雷。
- 现象：开发机时区是
CST（UTC+8），生产机是UTC，同一行数据查出来end_time差 8 小时 -
TIMESTAMP的自动转换只发生在插入/查询时，中间任何计算（比如end_time - NOW()）都在服务器时区下进行，逻辑混乱 - 兼容性风险：MySQL 5.6 和 8.0 对
TIMESTAMP默认行为有差异，升级可能触发隐式时区转换 - 建议：一律用
DATETIME+ 应用层管时区，或者用BIGINT存 Unix 时间戳（秒级），彻底避开时区解析
倒计时最脆弱的地方不在 SQL 写法，而在时间源是否可信、时区是否被悄悄转换。哪怕 NOW() 用对了，服务器时间漂移 2 秒，活动就可能卡在边界上反复横跳。
