并发查询的 MVCC 快照限制答案

【问题标题】：MVCC snapshot limit for concurrent queries并发查询的 MVCC 快照限制
【发布时间】：2020-02-23 11:32:28
【问题描述】：

我正在尝试学习 PostgreSQL MVCC 架构。它说 MVCC 为每个并发查询创建一个单独的快照。这种方式是不是内存效率低？

例如，如果有 1000 个并发查询并且表大小很大。这将创建表的多个实例。

我的理解正确吗？

【问题讨论】：

【解决方案1】：

它说 MVCC 为每个并发查询创建一个单独的快照。这种方式是不是内存效率低？

您可能会说这是内存效率低下。在实践中这通常不是什么大问题。

例如，如果有 1000 个并发查询并且表大小很大。

为什么你会有/想要 1000 个并发查询？你有1000个CPU吗？如果存在尝试建立 1000 个并发查询的风险，那么您应该部署一些入口控制机制（如连接池）来防止这种情况发生，并回退到 max_connections。

这将创建表的多个实例。

快照不是表的副本。只是一个set of information，它动态地应用于基表行以决定哪些行在该快照中可见。快照的大小与并发事务的数量成正比（一个原因不是 1000 个），而不是表的大小。

【讨论】：

这是一个很好的解释。只是一个疑问，是数据库服务器的max_connection属性吗？
postgresql中使用了什么，locking还是mvcc？
是的，max_connections 是在 postgresql.conf 中设置的数据库参数。 PostgreSQL 同时使用锁定和 MVCC。行锁会阻塞并发写入者，但不会阻塞纯读取者（即没有 FOR UPDATE 的读取者）。我不认为你可以拥有一个完全没有锁的 MVCC。
只有更改或新行被缓冲为新版本，所以它并不是整个表的快照，它只是看起来像一个，因为当你进行查询时，你只能“看到”时间戳小于或等于您的交易时间戳的数据。