Firebird 数据类型 - BLOB 子类型 1 或 VARCHAR(8000)

Question

我正在创建一个列，它需要保存可能非常长的数据。它不应达到 8000 个字符，因此我正在考虑使用 Firebird VARCHAR(8000) 数据类型 - 但我想以正确的方式执行此操作。

使用 varchar(8000) 还是 BLOB sub_type 1 会更有效吗？varchar(8000) 不会预先分配内存来容纳全部 8000 个字符吗？

哪个会更好？

Answer 1

在所有情况下，这两种选择都不是更好，因此在这方面，您的问题是基于意见的，无法真正回答。

选择 的VARCHAR(8000)优点是该值与记录的其余部分内联存储，从而减少了插入和查询所涉及数据的开销。作为缺点，它确实可能会在某些缓冲区中分配更多内存（尽管我实际上认为这不应该被视为缺点，而且我不确定那里的所有实现细节），并且考虑到行大小限制为 32768 字节，VARCHAR(8000) 将 - 根据字符集 - 从该最大值中获取 +/- 8000 - 32000 字节。由于记录的 RLE 压缩，实际存储大小会更小。

Ablob sub_type text是带外存储的，行本身只占用 8 个字节，但对于 4KB 的页面大小，实际大小可能略小于 4GiB，对于较大的页面大小，实际大小可能会更大（尽管某些内置函数可能无法超出4GiB），但 blob 需要与行本身分开创建或读取，因此插入和检索值会产生额外的开销。此外，由于 blob 是按页分配的，因此可能会导致额外的存储效率低下（例如，页面大小为 16384 的数据库中的 8000 个字符的 blob 将使用 16384 字节）。

简而言之，您需要权衡您的选择，甚至可能进行一些测试，然后做出选择（并且可能在情况发生变化时重新考虑该选择）。

例如，如果对该表的大多数访问不需要该字段的内容，那么 usingblob可能是更好的选择（只有在真正需要时才读取数据），另一方面，如果每次访问该字段table 也需要这些数据，那么 usingvarchar可能是更好的选择，因为数据将内联加载，而无需单独读取 blob。