❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

上期说数据库出海的文章，在群里有同学讨论这个问题。最近也在一直负责类似的事情，上期是从合规的角度来说这个问题，本期将从数据库本身出海适不适合来去讨论这个问题。

第一个问题出海本身对数据库选择有需求吗？ 这个问题的回答是肯定的，yes。出海的数据库产品是需要有选择的。

在这里我把我遇到的实际的问题梳理一下和大家讨论一下，出海的企业的数据库选择和使用中的思考必选项。

1 数据库表中的数据时间的表达的存储的问题。

从业务的角度，企业出海后，业务表中的时间存储是一个关键问题，比如日本，菲律宾，越南，新加坡，马来西亚等这些国家的时区是不同，不同的客户在不同的时间区域产生的数据记录的时间如何进行处理是一个大的业务逻辑问题。

这里牵扯第一个问题，数据库本身支持部支持UTC的时间存储，这是一个国际企业选择数据库的要求之一。

这里首先提到的就是MySQL,众所周知的一个问题，MySQL的存储时间的类型Datetime，他不支持时区的概念，也就是存储的是当时服务器所在时区的时间。这是非常，非常糟糕的。你在中国是OK的，我们可以以北京，上海时间作为时间的存储时间基准。但是如果你出国了，你的服务器在新加坡，他和北京的时间一样都是+8：00,可你的客户在日本和越南的情况下，他们一个时区是+9:00，一个是+7:00，他们使用一张表，MySQL的表记录的时间是+8:00的时区，这就导致展示给日本和越南的客户的时间是+8:00的时间。

业务不出大事才怪，所以出海的企业在数据库选择上第一个关键就是数据库对于时区的支持。有人说MySQL也支持时区的存储，timestamp但他只能存储到2038年所以在市区这个部分的支持性上，MySQL数据库不是一个好的选择。

同时PostgreSQL,ORACLE，MSSQL，MongoDB等数据库对于时区本身都有自己的支持性，也就是都有自己的特有的带有时区属性的字段类型可以支持这类出海企业对于时间存储的要求。这里典型的事MongoDB作为一个设计之初就为全球部署的数据库，他的时间类型 isodate 本身就支持UTC，所以在企业出海的时候，这类数据库在时间上就完全不存在问题。

上图中我们给出了一个业务表的设计，与我们普通的业务表中不同的是多个一个字段，这个字段叫时区字段，这里存储的是数据所在客户端的时区，比如从日本来的我们就在这个字段里面写9，如果是越来来的写7，新加坡的写8，而时间字段本身存储的是UTC的时间，我们这里以PG作为一个例子来说明。

当你向一个 TIMESTAMP WITH TIME ZONE 字段插入数据时，PostgreSQL 会执行以下操作： 解析输入时间：PostgreSQL 会首先解析你提供的时间字符串，并根据你当前会话的时区设置，确定这是一个具体的时刻（Instant）。转换为 UTC：然后，它会把这个时刻转换为 UTC 时间。

存储 UTC 值：最终，它只会在数据库中存储这个 UTC 时间戳。它并不会把时区信息（比如 +08 或 +09）存储在字段里。

举个例子：假设你当前会话的时区是 UTC+8（比如新加坡或北京时间）。

你执行 INSERT INTO my_table (event_time) VALUES ('2025-08-13 10:00:00 +08');PostgreSQL 会将 2025-08-13 10:00:00 这个时间点，转换为 UTC 时间，也就是 2025-08-13 02:00:00。数据库中实际存储的就是 2025-08-13 02:00:00 这个 UTC 值。

1. 数据读取 当你从 TIMESTAMP WITH TIME ZONE 字段中查询数据时，PostgreSQL 会执行相反的操作：读取 UTC 值：它从数据库中读取存储的 UTC 时间。

转换为会话时区：然后，它会根据你当前查询会话的时区设置，将这个 UTC 时间转换为相应的本地时间。返回转换后的时间：最后，它返回转换后的时间。

继续上面的例子：

假设你是一个在中国（UTC+8）的 DBA，执行 SELECT event_time FROM my_table;PostgreSQL 读取存储的 UTC 值 2025-08-13 02:00:00。

它发现你的会话时区是 UTC+8，于是将 UTC 时间加上8小时，返回 2025-08-13 10:00:00。假设你是一个在日本（UTC+9）的 DBA，执行 SELECT event_time FROM my_table;PostgreSQL 同样读取 UTC 值 2025-08-13 02:00:00。它发现你的会话时区是 UTC+9，于是将 UTC 时间加上9小时，返回 2025-08-13 11:00:00。

那么这样设计有什么好处

1 数据的一致性：你的服务器在哪里不重要，重要的是在哪里你的日期数据都是统一的。

2 方便查询和排序：因为时间是统一的UTC的时间，这给一些数据的统计和计算给予了方便性

3 展示的灵活性：如果是中国老板的企业开到了日本，那么他最终想获得的一些报表的数据可能是想用中国时间展示，那么UTC+上老板所在的时区就可以灵活展示数据。

我这一看字数，2500多字了，本来还想写一写审计与访问控制，多区域部署，以及数据库的部署方式的选择等，算了吧，等下期有时间咱们继续聊。

在企业出海时选择数据库尽量选择全球性的数据库产品，选可以在全球部署的，如AWS的产品，阿里云的产品，以及国内可以通用的产品。

另这里不得不提一句，OceanBase 兼容MySQL的版本已经解决了 2038年的限制，很符合全球数据库在时间上的条件。如果选择了OceanBase这样的产品，可以直接使用timestamp来在MySQL上使用UTC时间，这样就避免了后续很多由于时区变动产生的问题。

全球数据库的定义

全球数据库是一类能够 跨区域部署 的数据库架构，目标是：

1. 跨区域一致性：保证全球用户的数据写入、查询在不同地区保持一致或可控一致性。
2. 合规性：满足不同国家/地区（中国、欧洲、美国）的数据安全和隐私法规。
3. 高可用性：跨区域容灾与多活，避免单一数据中心宕机带来的全球性风险。

---

中欧美政策与合规差异

地区	法律/政策	要求	对数据库的影响
中国	《数据安全法》《个人信息保护法》	重要数据和个人信息必须境内存储，跨境传输需审批	必须有 中国境内部署，敏感数据不得直接跨境
欧洲	GDPR	数据必须存储在欧盟境内，跨境传输需 SCCs 或等效保护	欧洲本地集群  必须独立，传输需加密/脱敏
美国	HIPAA/CCPA 等行业法	无全国统一隐私法，要求相对宽松	更关注性能、低延迟和高可用，多采用云厂商全球数据库

---

全球数据库典型产品对比

数据库	技术特点	全球化能力	合规适应性	适用场景
Google Spanner	原生分布式，全局一致事务（TrueTime）	全球多活	合规需额外分区隔离	全球 SaaS、金融级一致性
AWS Aurora Global	主写 + 多区域只读副本，秒级同步	全球复制，低延迟	需客户侧数据分区治理	跨境读多写少业务
Azure Cosmos DB	多模型，多区域多活，5 种一致性级别	灵活一致性选项	合规需额外隔离策略	IoT、全球分布式应用
PolarDB（阿里云）	云原生分布式，兼容 MySQL/PostgreSQL/Oracle	支持多地域部署，但以阿里云为主	中国市场合规最佳，跨境需脱敏	中国企业出海，云原生场景
OceanBase	金融级分布式数据库，Paxos 强一致，HTAP 能力	可在多国际云（AWS、Azure、GCP、阿里云等）上部署 ，支持多租户+分区	中国境内合规最佳，欧洲可本地化，跨境可脱敏复制	全球金融、电信、电商，合规+高一致

---

置顶

免费PolarDB云原生课程，听课“争”礼品，重塑云上知识，提高专业能力