PostgreSQL：16个锁为何成为性能瓶颈
Sixteen Locks Ought to Be Enough for Anybody
PostgreSQL 中有一个鲜为人知的性能陷阱：每次查询都会对表上的每个索引加锁，无论是否真正使用。在 PostgreSQL 17 及更早版本中，快速路径（fast-path）锁数组仅有16个槽位，一旦查询涉及的锁超过这个数量，就会触发共享锁表竞争，导致 CPU 飙升和吞吐量下降。文章指出，使用 Prepared Statements 可绕过该问题，但受限于连接池配置；而 PostgreSQL 18 已彻底移除这一限制，将快速路径容量与 max_locks_per_transaction 绑定。更根本的解决之道，是审视并删除冗余索引——毕竟，21个索引的表，从来不该存在。
通过 PostgreSQL 17，每个后端只有16个快速路径锁槽位，一旦查询需要超过16个关系锁，就会回退到共享锁表，引发严重的锁竞争。