为什么要核对时区与字符集
迁移完成后最容易出问题也最难察觉的，是时间与编码口径不一致：应用服务器时区、数据库时区参数、操作系统 locale 与工具链编码不同，会引发报表日期错位、日志时间对不上、中文乱码与排序异常。它们通常不会让服务启动失败，所以能顺利通过功能验证，直到对账或导出报表时才暴露。核对方法与时间点本身也要留痕，便于事后解释数据差异。
基本信息
| 系统时间 | timedatectl 查看时区与 NTP 同步状态，确认时间源一致 |
|---|---|
| 数据库 | 时区参数、字符集与排序规则要逐库逐表核对 |
| 操作系统 | locale 与语言包，影响日期格式与文件编码处理 |
| 应用层 | 日志时间戳格式、业务时间字段与序列化时的时区 |
| 迁移后核对 | 源端与目标端用同一组命令采集，逐项比对 |
| 留痕 | 把采集结果与时间点记入验收材料 |
典型使用场景
- 数据库上云后的报表核对：发现日期分布与迁移前不一致
- 日志平台切换：确认采集与展示两端时区口径一致
- 跨地域部署：多地域实例时间一致才能做全局对账
- 定时任务异常：任务触发时间因时区变化提前或延后
- 中文乱码排查：迁移后导入导出文件出现乱码
- 排序异常：排序规则不同导致查询结果顺序变化
核对命令
核对命令
timedatectl # 时区、NTP 同步状态与本地时间
date # 当前时间与格式，注意输出里的时区缩写
locale # 语言与字符集环境变量
cat /etc/timezone 2>/dev/null; ls -l /etc/localtime # 时区配置文件
mysql -e 'SELECT @@global.time_zone, @@session.time_zone, @@character_set_server, @@collation_server;'
mysql -e 'SHOW VARIABLES LIKE "character_set_database";' # 逐个库核对建库字符集
# 建议对源端与目标端执行同一组命令，把输出并排比对后再切流常见不一致与后果
| 不一致点 | 表现 | 处理方向 |
|---|---|---|
| 应用与数据库时区不同 | 报表日期错位，跨零点数据落到错误日期 | 统一为同一时区口径，或明确在应用层做转换 |
| NTP 未同步 | 时间漂移，依赖时间戳的幂等与签名失效 | 配置可用的时间源并检查同步状态 |
| 字符集不一致 | 中文乱码、导入导出失败 | 统一建库与连接字符集，核对客户端编码参数 |
| 排序规则不同 | 同样查询返回顺序变化，唯一索引行为差异 | 迁移前核对排序规则并在目标侧对齐 |
| locale 缺失 | 日期格式与大小写转换异常 | 安装对应语言包并设置一致的环境变量 |
| 未留痕 | 事后无法判断数据差异是迁移导致还是业务本身 | 采集结果与时间点一并归档 |
核对时对源端与目标端使用同一组命令与同一时间点：不同时间点采集的结果无法直接比较，容易被时间漂移干扰判断。
上线后直接改数据库时区或字符集属于高危变更：已有数据的时间与编码含义不会自动随之转换，需评估后走变更流程。