Postgres vs MySQL索引锁：高并发写入密集场景下MySQL更具容忍性？

你的理解存在偏差，不能简单认为PostgreSQL锁页、MySQL只锁行，两者在锁机制上有几个核心差异需要关注：

1. PostgreSQL的索引页锁是短期、细粒度的辅助锁 #

PostgreSQL官方文档指出：B-tree、GiST和SP-GiST索引读写访问时使用短期共享/排他页级锁，在获取或插入每条索引行后立即释放锁。这些索引类型提供最高的并发度且不会出现死锁情况。

PostgreSQL的页级锁仅在单条索引行的读写操作过程中短暂持有，操作完成后立即释放，并非持续锁定整个数据页。同时，PostgreSQL本身具备行级（Tuple级）锁，在更新/删除行时会直接锁定对应的行记录，索引页锁只是索引维护时的临时锁，不会阻止其他事务操作同一页内的其他行。

2. MySQL InnoDB的"行锁"并非单纯的单记录锁 #

MySQL官方文档指出：行记录锁是对索引记录的锁。例如，SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;会阻止其他事务插入、更新或删除t.c1值为10的行。即使表未定义索引，行记录锁也始终会锁定索引记录……

InnoDB的行锁依赖索引，但在默认的可重复读（RR）隔离级别下，会启用**Next-Key Lock（间隙锁+记录锁）**机制：

• 不仅锁定匹配的索引记录，还会锁定记录之间的间隙，防止幻读
• 如果查询没有命中合适的索引，InnoDB会扫描全表并锁定所有扫描到的行，等效于大范围的行锁，反而会降低并发

而PostgreSQL在RR隔离级别采用快照隔离，无需依赖间隙锁来防止幻读，不会出现这种范围锁定的情况。

3. 高并发写入场景的实际表现 #

• PostgreSQL的短期页锁+行级锁组合，只要不同事务操作的行不冲突，同一数据页内的其他行依然可以正常操作，并发度并不低
• MySQL InnoDB在精准匹配索引的单记录更新场景下，行锁粒度确实更细；但如果存在大量范围查询或无索引查询，间隙锁或全表行锁会导致更多锁冲突，反而可能限制并发

综上，你关于"MySQL对高并发写入密集型应用容忍度更高"的结论并不准确，两者的锁机制各有细节，需要结合具体的业务场景（如查询类型、索引设计、隔离级别）来分析并发表现。

内容的提问来源于stack exchange，提问作者xuhdev