原文地址：https://www.bytebase.com/blog/features-i-wish-postgres-had-but-mysql-already-has在 Bytebase，我们对 Postgres 和 MySQL 两者都有较为深入的理解和实践经验。上期我们重点介绍了 Postgres 相比 MySQL 的优势；今天，我们将转而探讨 MySQL 擅长而 Postgres 不足的地方。Postgres 基于堆的存储结构和元组版本的 MVCC 机制在写密集场景中会产生更多开销（写放大）。虽然 Postgres 通过 HOT 更新等特性有所改进，但在重写负载下仍会产生更多 WAL 流量，并需要更频繁的 VACUUM 操作。MySQL 则采用聚簇索引存储和撤销日志，这在写重负载下性能更好。
详细比较可参考《Uber 从 Postgres 切换到 MySQL[1]》和《我们最讨厌 Postgres 的地方[2]》。Postgres 用户需要处理臭名昭著的事务 ID 环绕问题[3]，以及不太知名的 MultiXact 成员耗尽问题[4]。OrioleDB[5] 正在解决这些问题，但要达到 MySQL InnoDB 的成熟度还需要数年时间。[1] https://www.uber.com/blog/postgres-to-mysql-migration[2] https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html[3] https://blog.sentry.io/transaction-id-wraparound-in-postgres[4] https://metronome.com/blog/root-cause-analysis-Postgres-multixact-member-exhaustion-incidents-may-2025[5] https://github.com/orioledb/orioledbMySQL 的组复制提供单主和多主复制，内置自动故障转移和冲突检测功能。它通过内置的法定人数逻辑优雅地处理网络分区，自动确定哪个分区保持可写状态。Postgres 则依赖 Patroni、pg_auto_failover 等外部工具来实现类似功能。这些解决方案是有效的，但需要大量的运维开销和专业知识来正确配置和维护。Postgres 在版本 10 中引入的逻辑复制，仍在这方面试图追赶。它最大的限制是 DDL 操作不会被复制，而必须手动应用。MySQL 的不可见索引允许在不影响现有查询的情况下测试索引有效性，或临时禁用索引。这是生产数据库优化的重要特性。-- MySQL：创建不可见索引用于测试CREATE INDEX idx_orders_status ON orders (status) INVISIBLE;-- 使用不可见索引测试查询SET SESSION optimizer_switch = 'use_invisible_indexes=on';EXPLAIN SELECT * FROM orders WHERE status = 'pending';-- 确认有帮助后使索引可见ALTER TABLE orders ALTER INDEX idx_orders_status VISIBLE;
它还有助于索引维护策略：可以在删除索引之前先使其不可见，确保不会破坏任何查询后再安全删除。-- 使索引不可见以查看是否有影响ALTER TABLE orders ALTER INDEX idx_orders_status INVISIBLE;-- 如果不破坏查询则删除它DROP INDEX idx_orders_status ON orders;
Postgres 没有提供启用/禁用索引的内置语法；但可以通过切换 pg_index 表中的 indisvalid 字段作为替代方案。MySQL 生态提供了成熟的、开箱即用的在线 schema 变更工具，这是 Postgres 仍然缺乏的。如果表没有外键，可以使用 GitHub 的无触发器 gh-ost[6]；也可以选择 Percona 基于触发器的 pt-online-schema-change[7] 这一久经考验的解决方案。Postgres 社区已经开发了几个解决方案，但就采用率而言，没有一个能匹配 MySQL 的 gh-ost 或 pt-online-schema-change。[6]https://github.com/github/gh-ost[7] https://docs.percona.com/percona-toolkit/pt-online-schema-change.htmlPostgres 的每连接一进程模式能提供更好的隔离性，但它每个连接消耗更多内存，产生上下文切换开销，更容易达到连接限制。MySQL 的每连接一线程模式可能因为致命查询导致整个服务器崩溃，但更具可扩展性。Postgres 社区对此进行了全面讨论，见「让 Postgres 多线程化[8]」。但由于进程模型与 Postgres 的其余部分耦合过深，这将是一个相当具有挑战性的任务。[8]https://www.Postgres.org/message-id/flat/31cc6df9-53fe-3cd9-af5b-ac0d801163f4%40iki.fi
MySQL 至今仍是最受欢迎的开源数据库，是互联网时代实质上的标准数据库。让我们回顾两个推动其流行的支柱：务实的核心团队。原始的 MySQL 团队基于实际用例来优先考虑功能。- 复制作为在商用硬件上实现可扩展性和快速故障转移的最关键组件，在 2001 年的 MySQL 3.23 版本中引入，比 Postgres 在 2010 年（9.0 版本）添加复制功能早了近十年。
- 核心团队因缺乏优化存储引擎的带宽而设计了可插拔的存储引擎架构，这打开了 InnoDB 的大门。
活跃的社区。当互联网公司经历超高速增长，需要在商用硬件上运行高性能和可扩展的开源数据库时，MySQL 是显而易见的选择。Google 的初始广告系统、Twitter、Facebook、阿里巴巴和 GitHub 都选择了 MySQL。虽然有例外（如 Instagram 选择了 Postgres），但互联网时代大多数成功的公司都选择了 MySQL，并贡献了 MHA、RocksDB、gh-ost、复制改进等一系列增强功能。这培养了一代 MySQL 专家来推广技术，并催生了像 Percona 这样提供教育资源和 Percona 工具包等必备工具的专业咨询公司。浪潮滚滚向前，Postgres 已成为 AI 时代的新宠。虽然 MySQL 相比 Postgres 仍保留着一些架构优势，但它能否守住阵地，又是否会在 10 年内被淘汰？
Bytebase 3.8.1 - 新 CI/CD 流程体验预览
亲口尝试OpenAI Codex后，我又升级了【附详细使用截图】
那些我很希望 MySQL 有，但 Postgres 已经有的功能
开发者前沿 #12｜AI 原生员工颠覆传统企业组织架构
天舟约 4 分钟