数据库内部：可变大小字段如何处理？

Question

可变大小的字段似乎可能会导致性能问题。

为了具体起见，假设我们使用的是关系数据库。 假设一个关系具有可变长度的文本字段。 如果对关系中元组的更新增加了可变长度字段的大小，会发生什么？ 内联记录编辑（即，编辑包含内联记录的文件）将需要改组位于同一物理页面上的其他元组-可能会淘汰一些。

我知道不同的DBMS处理此问题的方式不同，但是我很好奇一些常用的做法。 在我看来，最好的方法是简单地将现有的元组标记为已删除，然后创建一个新的元组。

Answer 1

对于PostgreSQL，在http://www.postgresql.org/docs/9.3/static/datatype-character.html中有关于此的一些信息：

提示：除了使用空白填充类型时增加的存储空间外，这三种类型[varchar（n）/ character variant（n），char（n）/ charachter（n），text）之间没有性能差异。存储到受长度限制的列中时，需要几个额外的CPU周期来检查长度。 尽管character（n）在某些其他数据库系统中具有性能优势，但在PostgreSQL中却没有这种优势。 实际上，character（n）通常是这三个中最慢的，因为它需要额外的存储成本。 在大多数情况下，应改用文字或字符变化。

我假设由于数据完整性要求和事务处理（MVCC），“内联记录编辑”将永远不会发生。

关于事务处理，有一些（相当古老的）信息： http : //www.postgresql.org/files/developer/transactions.pdf

我们必须为每一行存储多个版本。 只有在将元组提交为已删除的时间足够长以致于任何活动事务都无法再看到它之后，才能删除该元组。

Answer 2

“这取决于”。 每种实现方式都是不同的，实际上需要保证自己拥有一本小书。 （我确实应该对这个问题进行投票，但不能回答，但我想我会尽力而为，我不能简短地发表评论）。

---

对于PostgreSQL，请阅读有关数据库存储和VARLENA ， 存储类和TOAST 的开发人员文档 ，以及有关MVCC和并发控制的手册部分 。 有关更多信息，请开始阅读代码，许多关键标头和源文件都有很好的详细注释，它们解释了低级操作。

精简版，您可能必须阅读上述资源才能理解：

PostgreSQL绝不会在更新期间覆盖元组。 它总是将其写入新位置。 如果该位置在同一物理页面上，并且没有更改索引，则它会避免索引更新，但是它将始终对新元组进行堆写入。 它设置了旧元组的xmax值和新元组的xmin，以便一个事务只能看到一个或另一个。 请参阅并发和mvcc文档以获取详细信息。

可变长度值可以内联或外联（TOAST）存储。 如果将它内联存储在堆的元组中（这是小值的默认值），则在更新记录（无论是更新该字段还是其他字段）时，数据将被复制到新的元组中，就像定长数据一样。 如果将它以离线方式存储在TOAST边表中，则如果未修改，则会复制指向它的指针，但不会复制其自身的值。 如果它是离线存储和修改的，则将新记录写入该值的TOAST表中，并将指向它的新指针存储在新保存的用于该新值的堆元组中。

后来，VACUUM出现并标记过时的元组，从而释放空间并允许它们被覆盖。

由于PostgreSQL必须保留旧数据以使旧事务可见，因此PostgreSQL绝对不能进行就地修改。

从理论上讲，可以将旧数据放到其他地方然后覆盖它-这就是Oracle所做的，带有其撤消和重做日志-但这不是PostgreSQL所做的。 这样做会带来不同的复杂性和折衷，解决问题并创造其他问题。

（无覆盖规则的唯一例外是pg_largeobject，它使用一种基于分片的写时复制功能，允许对大文件状的数据块进行事务更新，而无需复制整个文件。哦，您可能会说SEQUENCE被覆盖。还有一些全表锁定操作。）

---

其他RDBM的工作方式也不同。 有些甚至支持多种模式。 例如，MySQL使用MyISAM表（就地写入，AFAIK）和InnoDB（MVCC写入时复制）。 Oracle具有撤消和重做日志-它会将旧数据复制到离线存储中，然后进行就地更新。 毫无疑问，其他DBMS也再次有所不同。