Postgres 页锁 vs MySQL 行锁：并发写入性能谁更优？

2025-03-30 08:05:49

Postgres vs. MySQL 索引锁：MySQL 真能更好地处理并发写入吗？

咱们在比较数据库的时候，经常会抠一些细节。最近就有人翻看文档，发现 PostgreSQL 和 MySQL (InnoDB) 在索引锁定机制上有点不一样，然后得出一个初步结论：MySQL 的行锁是不是让它在处理大量并发写入时比 Postgres 的页锁更有优势？

这个问题问得挺好，直击痛点。毕竟，对于写操作密集的应用，锁竞争可是性能杀手。

我们先看看这两段官方文档是怎么说的：

PostgreSQL 文档 提到 B-Tree、GiST 和 SP-GiST 索引读写时用的是短期的共享/排他页级锁 。划重点：锁在每行索引处理完后立刻释放 ，并且号称这种方式能在没有死锁的情况下提供最高的并发度。
MySQL (InnoDB) 文档 说记录锁 (Record Lock) 是锁在索引记录 上的，也就是行锁。例子 SELECT ... FOR UPDATE 会阻止其他事务插入、更新、删除 c1 = 10 的行。并且强调，即使表没有显式创建索引，记录锁也总是锁定索引记录（通常是聚簇索引）。

光看字面意思，“页锁” vs “行锁”，直觉上确实会觉得锁的粒度越小（行锁），并发冲突的可能性就越低，MySQL 似乎占了上风。但数据库这东西，往往没那么简单。咱们得往深了扒一扒。

表面解读 vs. 实际机制

只看“页锁”和“行锁”这两个标签，容易产生误解。关键在于锁的具体实现、持有时间 以及与其他并发控制机制的协同工作 。

PostgreSQL 的锁策略：快速释放的页锁 + MVCC

Postgres 文档里那句 “Short-term” 和 “released immediately” 是关键。虽然它用了“页锁”，但这个锁更像是个快速开关。

短暂持有 : 当一个写操作（INSERT, UPDATE, DELETE）需要修改索引时，它会短暂地锁定包含目标索引条目的那个页面 。这个锁定时间非常非常短，通常只持续操作单个索引条目所需的时间。一旦操作完成，锁就立即释放，其他等待这个页面的进程就可以继续。
MVCC (多版本并发控制) : 这是 Postgres（以及 InnoDB）实现高并发的核心机制。读操作通常不会被写操作阻塞，反之亦然。当数据被更新或删除时，旧版本的数据不会立即消失，而是被标记为“过期”，同时生成新版本。读操作可以访问它们事务开始时“看到”的数据版本，不需要等待写操作完成。这极大地减少了读写冲突和对锁的需求。
原子操作优化 : 许多索引操作在底层被设计成高度优化的原子操作，进一步缩短了需要持有页面锁的时间。

所以，虽然是“页锁”，但因为它持有时间极短，并且只在精确操作的瞬间持有，大多数情况下并不会成为并发瓶颈，反而因为实现相对简单、开销小，能达到很高的吞吐量。文档里说的“最高并发度”并非空穴来风，尤其是在避免死锁方面（至少在常规索引操作层面）。

潜在冲突点 : 如果你的写入高度集中 在索引的同一个或相邻几个页面 上（例如，使用严格递增的序列作为主键，并且插入速度极快），那么这种短期的页锁还是可能造成争用。但这种情况在实际应用中可以通过一些设计来缓解（比如使用 UUID 做主键，或者调整填充因子 fillfactor ）。

MySQL (InnoDB) 的锁策略：行锁 + 间隙锁 + MVCC

InnoDB 确实以其行级锁闻名，这在理论上提供了非常细的锁粒度。

记录锁 (Record Locks) : 直接锁定单个索引记录。就像文档说的，WHERE c1 = 10 会锁住 c1 索引上值为 10 的那条记录。
间隙锁 (Gap Locks) : 这是 InnoDB 的一个特色，也常常是让人头疼的地方。为了保证“可重复读”（Repeatable Read）隔离级别下防止“幻读”（Phantom Reads），InnoDB 不仅会锁住找到的记录，还会锁定这些记录之间的“间隙”。比如，UPDATE ... WHERE age > 20 AND age < 30，如果索引上有 age=25 的记录，它不仅会锁住 age=25，还会锁住 (20, 25) 和 (25, 30) 这两个区间，阻止其他事务在这个区间插入新的记录。
Next-Key Locks : 这是记录锁和间隙锁的组合。它锁住索引记录本身，以及该记录之前的那个间隙。这是 InnoDB 在可重复读隔离级别下的默认行为。
MVCC : 和 Postgres 一样，InnoDB 也依赖 MVCC 来处理读写并发。大部分读操作（快照读）是不需要加锁的。

行锁的优势在于，如果两个事务要修改不同行 的数据，即使这些行在同一个数据页 或索引页 上，它们通常也不会互相阻塞（除非间隙锁介入）。

潜在冲突点 :

间隙锁/Next-Key锁 : 这是并发写入时最常见的“坑”。它们锁定的范围可能超出你的直觉预期，特别是在非唯一索引或者范围查询上，可能导致不相关的插入操作被阻塞，从而降低并发性能，甚至引发死锁。
死锁 : 虽然行锁粒度小，但更复杂的锁交互（比如事务 A 锁了行 1 等待行 2，事务 B 锁了行 2 等待行 1）同样可能导致死锁。间隙锁的存在有时会增加死锁的概率和复杂性。

锁粒度不是唯一标准

看到这里，你应该明白，不能简单地说“行锁一定比页锁好”。还得考虑其他因素：

MVCC 的关键作用

前面反复提到 MVCC。在现代关系型数据库里，MVCC 是处理并发的基础。大部分时候，是 MVCC 在默默支撑着高并发，让读写操作尽可能互不干扰。索引锁只是在 MVCC 无法解决冲突（主要是写-写冲突）时才出来干预。讨论锁策略，不能抛开 MVCC 这个大前提。

锁的持续时间与范围

Postgres 的页锁虽然范围大一点点（一个页面通常 8KB），但它持有时间极短 。MySQL 的行锁虽然范围小，但像 SELECT ... FOR UPDATE 这样的显式锁会持续到事务结束 。而且间隙锁的范围是动态的，有时可能锁住相当大一段“间隙”。谁的实际影响更大，真得看具体场景。

死锁的可能性

两者都可能发生死锁。Postgres 在常规 B-Tree 索引操作上声称无死锁，指的是其内部的短期页锁机制设计巧妙。但应用层面的逻辑错误，比如交叉更新多行，一样会导致死锁。MySQL 由于有间隙锁的存在，死锁的场景可能会更复杂一些，需要开发者对 InnoDB 锁机制有更深入的理解。

影响并发写入性能的其他因素

脱离实际场景谈锁策略就是耍流氓。真正影响并发写入性能的，除了锁本身，还有一大堆东西：

硬件资源 : CPU 核心数、内存大小、磁盘 I/O 速度是基础。资源不足，啥锁策略都白搭。
数据库配置 : shared_buffers (PG) / innodb_buffer_pool_size (MySQL) 的大小直接影响数据缓存命中率，减少 I/O；WAL (Write-Ahead Logging) 相关配置影响写入持久性和性能；连接池设置等。
表结构和索引设计 :
- 主键选择 : 连续递增主键 vs. UUID/无序主键，前者可能在索引末尾页造成热点，后者插入分布更均匀但可能导致页分裂更频繁。
- 索引数量和类型 : 过多的索引会增加写操作的负担，因为每个索引都要更新。选择合适的索引类型（B-Tree, Hash, GiST, GIN 等）也很重要。
- 数据类型 : 使用更紧凑的数据类型可以减少存储和 I/O。
查询模式 :
- 事务大小和持续时间 : 大事务、长事务会持有锁更长时间，增加冲突概率。尽量保持事务简短。
- 显式锁定 : 是否频繁使用 SELECT ... FOR UPDATE 或 SELECT ... FOR SHARE？这些锁会持续到事务结束。
- 写入分布 : 写入是均匀分布在整个表，还是集中在少数“热点”行或页面？
事务隔离级别 : 更高的隔离级别（如 MySQL 的 Repeatable Read 或 Serializable）通常意味着更强的锁定或更复杂的并发控制机制，可能影响性能。Postgres 的默认隔离级别是 Read Committed，通常锁竞争相对较少。

实践建议

理论分析一堆，最终还是要落地。想知道你的应用在哪种数据库上跑得更好，光看文档不行，得动手试试。

1. 基准测试是王道

永远不要假设，要去测试！ 针对你的真实或模拟的写密集型工作负载，在配置相似的 Postgres 和 MySQL 环境上进行基准测试。

工具 : 可以用 pgbench (Postgres 自带) 或 sysbench (通用，支持两者) 来模拟 OLTP 负载。更复杂的场景可能需要自己写脚本。
监控 : 测试期间，密切关注 CPU、内存、I/O 使用率，以及锁等待 情况。

2. 理解你的工作负载

你的“写密集”具体是什么样的？

是大量 INSERT？还是 UPDATE？或者 DELETE？
UPDATE 是更新同一行的不同字段，还是更新很多行的某个字段？
写入的数据有模式吗？是随机分布还是有热点？
事务的平均时长是多少？

搞清楚这些，才能有的放矢地分析瓶颈。

3. 优化索引和查询

精简索引 : 只创建确实需要的索引。
索引维护 : 定期 VACUUM ANALYZE (PG) 或 OPTIMIZE TABLE (MySQL，但要小心锁表) 来维护表和索引的统计信息和物理结构。
查询优化 : 确保 SQL 语句高效，避免全表扫描，减少不必要的锁定。
批量操作 : 如果可能，将多个单行操作合并为批量操作，减少事务和锁开销。

4. 监控锁等待

当性能出现问题时，得知道是不是锁惹的祸。

PostgreSQL :

查询 pg_locks 视图可以看当前持有的锁。
查询 pg_stat_activity 视图，关注 wait_event_type 和 wait_event 列，看是否有 Lock 相关的等待。
使用 pg_stat_statements 扩展分析慢查询。

-- 查看当前活跃的锁
SELECT locktype, relation::regclass, page, tuple, virtualtransaction, pid, mode, granted
FROM pg_locks
WHERE relation IS NOT NULL;

-- 查看正在等待锁的进程
SELECT pid, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE wait_event_type = 'Lock';

MySQL (InnoDB) :

SHOW ENGINE INNODB STATUS; 是个神器，输出信息非常丰富，包含最新检测到的死锁信息、事务和锁的信息。
查询 information_schema.INNODB_LOCKS 和 information_schema.INNODB_LOCK_WAITS 表可以获取当前的锁和锁等待信息。
Performance Schema 提供了更细粒度的性能和锁监控能力。

-- 查看 InnoDB 状态，留意 LATEST DETECTED DEADLOCK 和 TRANSACTIONS 部分
SHOW ENGINE INNODB STATUS\G

-- 查看当前存在的锁
SELECT * FROM information_schema.INNODB_LOCKS;

-- 查看当前锁等待关系
SELECT
    r.trx_id AS waiting_trx_id,
    r.trx_mysql_thread_id AS waiting_thread,
    r.trx_query AS waiting_query,
    b.trx_id AS blocking_trx_id,
    b.trx_mysql_thread_id AS blocking_thread,
    b.trx_query AS blocking_query
FROM information_schema.INNODB_LOCK_WAITS w
JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id
JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id;