GoForum › 🌐 V2EX

用了十几年的 MySQL 了，突然发现 PostgreSQL 可能更加适合我，大家怎么看？

Rooger · 2025-12-27 11:00 · 0 次点赞 · 10 条回复

从 13 年毕业开始就开始使用 MySQL ，当时不理解 DBA 把用户表分成了 100 张，后来在别人的一通解释下也渐渐理解了。

17 年自己开始作为主程负责一个新项目，当时因为把用户表分成 100 张还跟老板吵过架（因为当时另外一个项目的负责人本身就是个混混，还给老板一通乱说，弄的我特别郁闷，无奈自己当时的心理素质不是特别强大）。后来我也觉得 100 张表可能太多了，可能没有那么多用户，索性就只分了十张。

20 年新的项目，开始尝试使用 MongoDB ，经别人推荐，说 MongoDB 怎么适合游戏。当时觉得这东西好啊，但是在实际使用时，并不是那么美好。

24 年另外一个项目，负责人全部使用了 MongoDB ，但是用法相当暴力，也就是每次全量存储用户的数量到 MongoDB 中，感觉跟使用 MySQL 也没有什么实质性的区别。

今年负责另外一个项目时，最开始设计者将用户的 JSON 数据先进行 base64 encode ，然后异或加密存储到了 MySQL 中。因为最开始的客户端的设计是纯单机，后面加了服务器存储用户的存档而已。

新的需求是要将这个单机版本做成一个联网版本，因为我之前有将单机变成联网的成功经验（某合成游戏变成联网版本，国内流水过五亿）。

现在的存储结构没有规划过，JSON 结构下面有超过 200 个字段，活动配置占用超过了 90% 的存储以上，平均用户的存储占用在 100KB 以上。存档中存储活动配置的原因：活动开启之后，则配置不再发生变化。

我重新设计了存储结构，使用 Protobuf 重新设计了数据存储，将活动配置数据跟游戏存档分离。活动配置单独存档在一张配置表，用户的存储中只记录对应的唯一 ID 。同时提供了接口，可能将旧的数据转换为新的 Protobuf 存储结构。

用户的数据存储中，使用 JSON 存储，存储的内容为 Protobuf 对应的 JSON 数据。用户更新数据时，提供了 FieldMask 仅修改部分数据（只前每次都是全量更新）。

当这个版本成功上线之后，我发现某些接口调用比较慢，例如在用户转换存档时，我将客户端提供的原始数据、转换之后的结果存储到了 conversion_logs 配置表（数据类型均为 JSON ），内网的虚拟机上平均耗时为 200ms 。因为最近在研究 PostgreSQL ，索性就试了一下性能对比，结果 PG 只需要 20ms 左右。最关键的是，表空间存储的占用上，PG 远低于 MySQL ，因为 PG 存储使用的类型为 JSONB 。

我尝试对比纯 TEXT 字段的记录时，PG 占用的空间也只有 MySQL 的 ¹⁄₃ ，现在的数据表现就是在存储和插入速度 MySQL 远低于 PG 。更新的速度还没有完全验证。

SELECT
  table_name,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb,
  ROUND(data_length / 1024 / 1024, 2) AS data_mb,
  ROUND(index_length / 1024 / 1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_schema = 'merge_island'
  AND table_name IN ('conversion_logs','game_saves','activity_saves','activity_config');
  
+-----------------+----------+---------+----------+
| TABLE_NAME      | total_mb | data_mb | index_mb |
+-----------------+----------+---------+----------+
| activity_config |   216.83 |  209.55 |     7.28 |
| activity_saves  |     0.16 |    0.16 |     0.00 |
| conversion_logs |    70.55 |   70.52 |     0.03 |
| game_saves      |     7.48 |    7.39 |     0.09 |
+-----------------+----------+---------+----------+

SELECT
  relname AS table_name,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
WHERE relname IN ('conversion_logs','game_saves','activity_saves','activity_config');
table_name    | total_size
-----------------+------------
 activity_config | 32 MB
 activity_saves  | 376 kB
 conversion_logs | 13 MB
 game_saves      | 1976 kB

另外把用户分为 100 张的操作在 PG 这里完全是反模式的，因为 PG 号称单表轻松过亿。另外十多年前的老设计本应该也要被淘汰了，毕竟现在都是云服务，空间存储可以轻松扩充，不用再担心这个问题。

有没有使用 PG 淘汰 MySQL 的大佬来分享一下自己的经历，一起学习哈。

10 条回复