时区与跨天边界
跨时区系统的日期边界是事故高发点。源库常用 UTC 存储，数仓分区按业务时区（东八区）切分，两者混用会把当日数据整体切到前一天。校验关注三件事：时间字段是否带明确的时区语义、跨天边界样本（前后各半小时）落在哪个分区、小时分布是否有整体偏移。时区问题往往到月末对账才暴露，例行抽查比事后追查便宜得多。
基本信息
| 常见组合 | 源库 UTC + 数仓 Asia/Shanghai（UTC+8） |
|---|---|
| 高危字段 | created_at、updated_at、分区字段 dt |
| 校验方法 | 边界样本抽查、小时分布对比、与源端抽样核对 |
| 归一策略 | 入口层统一转业务时区，再生成分区 |
| 特殊情况 | 夏令时地区的重复小时与缺失小时 |
典型使用场景
- 跨时区同步上线后：抽查 23:30~00:30 的记录落在哪个分区
- 月末对账前：核对分区字段的时区口径是否与业务日一致
- 小时分布出现 8 小时整体偏移：排查是否 UTC 直落分区
- 夏令时切换当日：检查是否有重复或缺失的小时数据
- 自然日报表需求：确认业务日的界定与分区边界一致
边界样本抽查
边界样本抽查
SELECT order_id, created_at
FROM ods_orders
WHERE created_at BETWEEN '2026-10-10 23:30:00' AND '2026-10-11 00:30:00'
LIMIT 50;小时分布对比
小时分布对比
-- 正常业务应呈现自身日周期；整体平移 8 小时即可疑
SELECT HOUR(created_at) AS h, COUNT(*) AS cnt
FROM ods_orders
WHERE dt = '2026-10-11'
GROUP BY HOUR(created_at)
ORDER BY h;MySQL 8 显式转换
MySQL 8 显式转换
-- 显式转换，避免依赖会话时区设置
SELECT order_id,
created_at AS ts_raw,
CONVERT_TZ(created_at, '+00:00', '+08:00') AS ts_bj
FROM ods_orders
WHERE dt = '2026-10-11'
LIMIT 10;
-- 使用命名时区（如 UTC、Asia/Shanghai）需先导入时区表边界偏移症状对照
| 症状 | 可能原因 | 核对方法 |
|---|---|---|
| 当日数据整体落到前一天 | 源端 UTC 直接落分区 | 比对源端时间与分区字段 |
| 跨天记录数量异常翻倍 | 夏令时回拨导致重复小时 | 检查切换日的时间序列 |
| 月初分区行数为 0 | 偏移把数据推到上月末 | 查上月末分区是否异常膨胀 |
| 23~24 点几乎无数据 | 聚合脚本按 UTC 日界截断 | 核对聚合的时间过滤条件 |
分区字段用业务时区生成，并与源端抽样核对：时区问题往往在月末对账时才暴露。
时间字段类型也影响判断：MySQL 的 TIMESTAMP 按会话时区转换存储与展示，DATETIME 不做转换，跨库比对时要把这一点算进去。