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

[Rooger]

从 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 的 1/3 ，现在的数据表现就是在存储和插入速度 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 的大佬来分享一下自己的经历，一起学习哈。

[idihs]

用乔布斯的话来说，应该是我们有一个牛逼的需求，让我们去选一个技术去实现吧；而不是我有一个牛逼的技术让我们去做点什么吧。(❁´◡`❁)

[Georgedoe]

PG 支持的场景更多,如果想用一个数据库干所有事的话那确实 PG 更合适

[xuld]

我一直认为，PgSql 在各方面都要优于 MySql 。而 MySql 只有一个优势：发布更早（因此存量用户更多）。
但现在仍有很多新老项目在使用 MySql ，主要原因不是因为 MySql 更优秀，而是：
1. 虽然 PgSql 在很多地方优于 MySql ，但 MySql“也不是不能用”，没有决定性的放弃 MySql 的理由。
2. 大部分程序员只会按习惯工作，拒绝接受新技术，对新技术有未知的恐慌感，他们只接触过 MySql ，让他们放弃 MySql 会有莫名的不安。
3. 老项目如果 MySql 跑的好好的，不存在理由去升级它，毕竟大家都是打工心态，多一事不如少一事。
4. PgSql 服务器成本目前略高于 MySql 服务器。

[stinkytofux]

看来我也需要尝试一下 PgSql 了, 正如楼上所说, MySql 不是不能用, 没有那么多牛逼的项目要做.

[BeijingBaby]

mysql 从管理上来讲更熟就应该继续用 mysql ，
pgsql 如果你没有多年的管理经验，后续可能还有很长的坑要踩哦。。。

[frankilla]

作为一个门外汉，pgsql 部署简单很多，以前光看数据库部署教程都麻了，别更说真去部署。

[ratazzi]

不说别的，PG 有几个特性我觉得非常实用省心
1. varchar 不强制长度限制，不会出现错误长度估算导致数据被截取之类的问题
2. partial index 可以轻松实现 软删、取消等场景不唯一 但非软删、有效状态的唯一限制，这种事情代码和人真靠不住

[chqome]

公司以前用的 oracle ，后来全面转向 PostgreSQL 了

[vopsoft]

MySQL 5.7 后就支持 JSON 了
PG 不是很了解，例如它的集群 HA 是怎么弄的？

[everhythm]

pg 是啥啥都能干，nosql jsonb ，时序数据库，向量数据库，虽然不是各个领域最好的，但是作为业务起步完全没问题

pg 的底层设计也是领先 mysql 的，叠加国产信创，后面用 pg 的会越来越多

[bootvue]

pg 某些方面性能确实好 但是没好到碾压 mysql 的地步 真到了很大规模的业务量 业务侧 数据库选型 多种数据库组合用要综合考虑

[midsolo]

刚参加工作时，在某快递厂，项目使用 Mycat 进行分库分表，24 个库每个库 16 张表，一个 MHA 管理着 24 套 MySQL 主从。

8 年过去了，现在项目用 Sharding-JDBC 进行的分库分表，8 个库每个库 64 张表，买了一堆的 Amazon RDS MySQL 。

[dzdh]

@vopsoft
mysql 的 json 的 crud 仅仅实现了 R 吧。跟 PG 比就真的是萤火比之皓月，水分子比之江洋

PG 的 HA 最新版本仍然是主从，然后通过逻辑复制订阅槽进行同步

方案很多，比如 citusdb ，可以做 shard nothing. 社区版最近已经支持 rebalance 了。

timescaledb 做时序检索

pgroonga unicode 的全文检索

pgvector 做 RAG 知识库

pgstorm GPU 加速

postgis GIS 的事实开源标准


插件生态极其强大

[superchijinpeng]

pg 现在远优于 mysql ，现在很多开源服务都在慢慢移除 mysql 支持

[MoGeek]

气氛都烘托到这里了，我必须给你推一个绿泡泡号：老冯云数，欢迎加入 pg 邪教。

[sofukwird]

有什么好看的, 现在都是一边倒的 pg, 选 mysql 都算是 49 年入国军了

[xaxb]

Pgsql 在部分特性（数据类型，插件生态）上确实有吸引力，mysql 也并未全面落后，感觉有几点 MySQL 是有优势的：多平台稳定支持，热点数据更新下 undo redo 机制优于 pgsql tuple 的 Wal(因此 uber 换回 MySQL),mysql 支持在普通 sql 里定义变量，除非硬需，没必要换成 pgsql

[FrankAdler]

感觉 mysql 是简单易用吧，复杂的理论不多，就是存数据查数据，
做为一个门外汉看 pgsql 就麻烦很多，超管是个本地用户，跟很多人以为的是一个账号有超管权限不一样，命令行登录数据库还要切用户？诡异，
然后各种命令缩写，什么\c \l \q ？应该有大部分人跟我一样都挺讨厌缩写的，因为难记，还有就是很难靠惯性和已有认知去理解注记，比如 IBM 你知道是啥，但是 DDS 你告诉我是什么？哦原来是打 Apex 的有个主播叫蛋蛋鼠的缩写。list user mappings 的命令是\deu ，请问我该死记硬背呢还是死记硬背

然后 template01 的，默认用户不隔离的，自增时间这些感觉，都挺不喜欢的

[hushao]

我就说一个

MySQL 的更新活动趋势上在大幅减少。就这样一个理由就够你赶快规划脱离了，非要等到人家宣布停更再艰难切割么

[mark2025]

技术层面 mysql 就一垃圾（尤其是 isam 引擎），应用层面就一玩具

[mark2025]

pg 优点可以参考老冯的 https://pigsty.cc/blog/

[julyclyde]

虽然，但是你这个数据的 schema 是不是太松散了，居然用 json 来存吗？

[kakki]

十年前就不用 MySQL 了

[ano]

那就换吧

[xuhuanzy]

MongoDB 在游戏方面有啥缺陷？能说说吗？
虽然 pgsql 的 jsonb 也很不错，但在复杂场景下相比 mongodb 仍缺乏很多实用功能吧，从索引到排序

[icyalala]

后端技术栈真是稳定，十几年前我还是做后端的时候就在用 mysql 分库分表，mongodb 存些 json ，现在还能用。。
反观前端和客户端...

[akira]

你是靠 mysql 赚钱的么。。 不是的话， 为啥会有这个问题呢。。

[bjfane]

17 年 分表从 100 张分到 10 张，然后呢。。。啥都没影响？

[vopsoft]

@dzdh 解决方案不在于多，而在成熟稳定，毕竟数据无价。

Ps MySQL 目前有坑的包括
pxc
mgr
mycat （坑巨大）

[rambeaufinal]

想换就换。PG 一堆坑等着你。慢慢踩呗。

[BD8NCF]

没有更多细节，无法评论哪种选择更好。但是，虽然 op 的描述带有一些测试时间对比之类的，其实更多是感性的，而不是技术的。本质上，你只是想找一些认同而已。

[liuliuliuliu]

mysql 本来就是最垃圾的之一，可能比 access 强点吧……
换个更好的没啥问题