OLTP 数据库篇：MySQL、PostgreSQL 与业务系统的数据库选择

OLTP 是 Online Transaction Processing，在线事务处理。它面对的不是一次扫十亿行的分析查询，而是大量短小、频繁、对正确性要求很高的业务请求。

用户注册、登录、下单、支付、退款、库存扣减、账户余额变更，这些都属于典型 OLTP 场景。它们的共同特点是：每次操作影响的数据量不大，但请求频率高，并且不能错。

Rendering diagram...

OLTP 数据库关心什么

OLTP 数据库的第一目标是正确。订单不能重复扣款，库存不能扣成负数，账户余额不能因为并发更新而丢失。

第二目标是低延迟。用户点击支付后，系统不能等几十秒才返回。大量 OLTP 请求都希望在毫秒到几十毫秒级完成。

第三目标是高并发。业务系统同时面对大量用户请求，数据库要能处理并发读写、锁冲突和事务隔离。

第四目标是可恢复。机器宕机后，已经提交的事务不能丢，未完成的事务不能留下半截状态。

MySQL：工程实践里的默认选择之一

MySQL 是互联网业务系统里最常见的 OLTP 数据库之一。它的优势不只是数据库内核本身，还包括成熟生态、丰富运维经验、稳定复制方案、广泛的工具链和大量工程师的熟悉度。

在 MySQL 中，InnoDB 是最重要的存储引擎。现代 MySQL 的事务、行级锁、崩溃恢复、MVCC、外键、聚簇索引等核心能力，基本都围绕 InnoDB 展开。

InnoDB 的主键索引是聚簇索引。也就是说，表数据本身按照主键索引组织。这个设计让主键查询非常高效，但也意味着主键选择会影响数据组织方式。业务中常见的自增主键、雪花 ID、UUID，在写入局部性和索引体积上会有不同影响。

MySQL 很适合用户系统、订单系统、支付流水、后台管理、内容管理、配置管理等传统业务场景。它的 SQL 能力够用，事务能力成熟，复制和备份工具多，遇到问题也容易找到经验。

MySQL 的典型挑战在于复杂查询、分析型负载和高级 SQL 能力。虽然 MySQL 也能做聚合、Join、窗口函数，但它不是为大规模 OLAP 扫描设计的。把大量报表查询直接打到 MySQL 主库上，是很多业务系统性能问题的源头。

一个典型 MySQL 订单表会围绕点查、用户订单列表和状态流转设计索引：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(64) NOT NULL,
  user_id BIGINT NOT NULL,
  status VARCHAR(32) NOT NULL,
  pay_status VARCHAR(32) NOT NULL,
  total_amount DECIMAL(12, 2) NOT NULL,
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  UNIQUE KEY uk_orders_order_no (order_no),
  KEY idx_orders_user_created (user_id, created_at),
  KEY idx_orders_status_created (status, created_at)
) ENGINE=InnoDB;

PostgreSQL：更强调能力完整性的关系数据库

PostgreSQL 通常被称为功能非常完整的开源关系数据库。它的特点是 SQL 能力强、类型系统丰富、扩展机制灵活，对复杂查询、事务语义、数据完整性和可扩展性支持都很扎实。

PostgreSQL 的 MVCC 设计是理解它的重要入口。读请求通常可以读取一致性快照，写请求创建新版本，从而减少读写之间的直接阻塞。它通过 VACUUM 等机制清理旧版本数据，这也让 PostgreSQL 的运维里经常会关注膨胀、冻结、统计信息和自动清理。

PostgreSQL 的强项包括复杂 SQL、窗口函数、CTE、JSONB、数组、全文检索、地理空间扩展 PostGIS、外部数据包装器 FDW、丰富的扩展生态等。很多场景下，它不只是一个传统业务库，也能承担轻量分析、搜索、GIS、向量检索等扩展任务。

如果一个系统需要复杂数据模型、复杂查询、强约束、丰富类型，PostgreSQL 往往会比 MySQL 更舒服。尤其是当业务不仅是简单 CRUD，而是有很多关系表达、数据校验和查询组合时，PostgreSQL 的优势会更明显。

PostgreSQL 的挑战在于团队熟悉度、运维经验和某些高并发写入场景下的调优复杂度。它很强，但要发挥好，也需要理解 autovacuum、索引膨胀、统计信息、执行计划和连接管理。

PostgreSQL 的优势经常体现在类型、约束和扩展能力上：

CREATE TABLE product_events (
  id BIGSERIAL PRIMARY KEY,
  user_id BIGINT NOT NULL,
  event_name TEXT NOT NULL,
  properties JSONB NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_product_events_properties
  ON product_events USING GIN (properties);

SELECT *
FROM product_events
WHERE properties @> '{"sku_id": "sku_10001"}';

MySQL 和 PostgreSQL 的主要差异

从工程视角看，MySQL 更像是“稳定、普及、生态成熟的业务系统默认件”。PostgreSQL 更像是“能力完整、语义严格、扩展性强的关系数据库平台”。

在生态上，MySQL 在传统互联网业务、主从复制、分库分表、中间件、云数据库产品上有非常深的积累。PostgreSQL 在复杂查询、扩展能力、数据类型和标准 SQL 支持上更突出。

在索引和存储上，MySQL InnoDB 使用聚簇主键索引，二级索引叶子节点通常保存主键值。PostgreSQL 的表数据和索引组织方式不同，索引指向表中的元组位置，MVCC 旧版本清理也会影响表和索引维护。

在 JSON 能力上，MySQL 有 JSON 类型和相关函数，适合一般半结构化字段。PostgreSQL 的 JSONB、GIN 索引和函数生态更强，复杂 JSON 查询和索引能力通常更有优势。

在扩展能力上，PostgreSQL 明显更像一个可扩展数据库平台。PostGIS、pgvector、TimescaleDB 等扩展让它能进入 GIS、向量检索、时序等场景。MySQL 的扩展生态相对没有 PostgreSQL 这么开放。

在运维和团队成本上，MySQL 的普及率和经验沉淀通常更有优势。很多团队对 MySQL 的备份、复制、监控、慢查询治理、分库分表更熟悉。PostgreSQL 则要求团队更认真理解数据库内部行为，尤其是 MVCC 版本清理和执行计划。

维度	MySQL	PostgreSQL
常见定位	互联网业务系统默认选择之一	能力完整的关系数据库平台
存储代表	InnoDB	PostgreSQL 原生存储与 MVCC
生态优势	运维经验、复制方案、云服务、中间件丰富	SQL 能力、扩展生态、复杂类型
JSON 能力	支持 JSON 类型和函数	JSONB + GIN 索引能力更强
适合场景	常规业务系统、订单、用户、后台	复杂查询、强约束、GIS、向量、JSON
典型挑战	复杂分析容易压垮业务库	autovacuum、膨胀、统计信息需要治理

怎么选择

如果你的业务是典型互联网应用，主要是用户、订单、商品、支付、后台管理，团队对 MySQL 更熟，基础设施也围绕 MySQL 建好了，那么 MySQL 是非常稳妥的选择。

如果你的业务有复杂 SQL、复杂数据类型、强约束、复杂报表、GIS、JSONB、向量检索或者希望用一个数据库覆盖更多能力，PostgreSQL 值得优先考虑。

如果你已经预期单机 OLTP 很快会到瓶颈，需要水平扩展、强一致和分布式事务，可以进一步评估 TiDB、OceanBase、CockroachDB 这类分布式 SQL 数据库。但它们不是免费午餐，会带来更高的架构和运维复杂度。

OLTP 常见设计建议

第一，事务要短。不要在事务里做远程调用、复杂计算或等待用户输入。事务越长，锁占用越久，冲突越明显。

第二，索引要围绕查询设计。高频查询条件、排序字段、唯一约束都值得关注，但低频字段不一定需要索引。

第三，不要让报表查询直接压垮业务库。复杂聚合、历史数据扫描、多维分析，应该同步到 OLAP 或报表库。

第四，状态变化要留痕。订单状态、支付状态、退款状态，最好有状态日志。只保存最终状态会让排查和报表都很痛苦。

第五，缓存不能替代数据库正确性。Redis 可以做热点加速，但核心状态仍然要有可靠的持久化和事务边界。

小结

OLTP 数据库是业务系统的心脏。它不追求一次查询扫完海量历史数据，而是追求每一次业务写入都正确、稳定、可恢复。

MySQL 的优势是成熟、普及、生态完整，适合大量传统业务系统。PostgreSQL 的优势是 SQL 能力、扩展性和复杂数据表达，适合对数据库能力要求更高的系统。

真正的选择不是“谁更先进”，而是看业务模型、团队经验、运维能力和未来演进方向。

参考链接

• MySQL 8.4 Reference Manual: The InnoDB Storage Engine
• MySQL 8.4 Reference Manual
• PostgreSQL 18 Documentation: Chapter 13. Concurrency Control
• PostgreSQL 18 Documentation: Transaction Processing

社区讨论参考

• 知乎：What are the advantages of PostgreSQL over MySQL?
• 知乎：How to choose between PostgreSQL and MySQL?