企业出海数据库设计问题一角，与政策动荡下的全球数据库产品

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

第一个问题出海本身对数据库选择有需求吗？ 这个问题的回答是肯定的，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. 高可用性：跨区域容灾与多活，避免单一数据中心宕机带来的全球性风险。

中欧美政策与合规差异

全球数据库典型产品对比