mysql 5.7/8.0 中 now() 和 current_timestamp 时区行为不一致：5.7 在时区表未加载时静默回退系统时区，8.0 则报错或返回 null；convert_tz() 强依赖时区表，缺失时恒返 null；date() 等函数结果随会话时区漂移，跨时区统计应先转时区再截取或由应用层处理。
NOW() 和 CURRENT_TIMESTAMP 在 MySQL 5.7/8.0 中的时区行为不一致
这两个函数在 MySQL 5.7 和 8.0 中都受 @@time_zone 控制，但 8.0 默认启用 STRICT_TRANS_TABLES，导致某些时区转换失败时直接报错，而 5.7 可能静默回退到系统时区。比如执行 SET time_zone = 'Asia/Shanghai'; SELECT NOW();，若 MySQL 时区表未加载（mysql.time_zone 空），5.7 返回本地时间，8.0 可能返回 NULL 或报错 ERROR 1298 (HY000): Unknown or incorrect time zone: 'Asia/Shanghai'。
- 检查时区是否生效：运行
SELECT @@time_zone, NOW(), CONVERT_TZ(NOW(), '+00:00', 'Asia/Shanghai');，后者返回 NULL 就说明时区数据没加载 - 修复方式不是改 SQL，而是用
mysql_tzinfo_to_sql导入系统时区表，并重启 mysqld - 避免在建表 DEFAULT 子句里写
CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP后再设会话时区——5.7 下该 DEFAULT 仍按服务器时区计算，8.0 才真正按会话时区解析
CONVERT_TZ() 在跨版本迁移中极易失效
CONVERT_TZ() 表面是“标准函数”，实则强依赖 MySQL 内置时区库。MySQL 5.7 安装后默认不加载时区表；8.0 虽带 --initialize-insecure 自动初始化，但若用 rpm/deb 包安装，仍可能跳过这步。一旦缺失，CONVERT_TZ('2026-08-27 00:00:00', '+00:00', 'Asia/Shanghai') 永远返回 NULL，且无任何警告。
- 不要把
CONVERT_TZ()用在 WHERE 条件或 JOIN 关联字段上——NULL 结果会导致整行被过滤，排查极难 - 生产环境上线前必须验证：连进数据库执行
SELECT COUNT(*) FROM mysql.time_zone_name;，结果应 > 0 - 替代方案更稳：应用层做时区转换，或统一用
TIMESTAMP类型存 UTC 时间，查时只做DATE_ADD(dt, INTERVAL 8 HOUR)这类确定性偏移（仅限固定 UTC+8 场景）
DATE() / HOUR() 等提取函数在跨时区聚合时隐式依赖会话时区
DATE(event_time) 看似只是截日期，但它对 event_time 的解释完全取决于当前会话的 @@time_zone。如果 event_time 是 DATETIME 类型（无时区语义），而你连接时没设 serverTimezone，JDBC 驱动可能按客户端本地时区解释，导致 DATE('2026-08-27 00:00:00') 在北京时间会话中返回 '2026-08-27'，在 UTC 会话中返回 '2026-08-26'。
- 永远不要在 GROUP BY 或 WHERE 中直接用
DATE(created_at)做跨天统计——它无法利用索引，且结果随连接时区漂移 - 正确做法是先转目标时区再截取：
DATE(CONVERT_TZ(created_at, '+00:00', 'Asia/Shanghai'))，但前提是确认CONVERT_TZ可用 - 最可靠的是让应用传入已对齐的日期范围字符串，如
WHERE created_at >= '2026-08-27 00:00:00' AND created_at ，并确保该字符串按 UTC 或目标时区生成
时区问题从来不在函数名本身，而在函数执行时所处的上下文：连接参数、会话变量、字段类型语义、甚至驱动版本。一个 NOW() 在不同环节可能被解释成服务器时间、UTC 时间、客户端本地时间——不验证就假设“它应该一样”，是线上时间类 bug 最常见的根源。
