如何达到每行 8060 字节和每个(varchar、nvarchar)值 8000 个字节的限制?

发布于 2024-09-25 12:08:25 字数 513 浏览 7 评论 0原文

来自我的问题“8060 B 数据页中的 8078 字节(SQL Server )?”,其中向我解释了如何在 MS SQL Server 中导出每页 8078 字节的数据。

如果我计算每页用于仅一行和一列非索引固定大小类型记录的数据存储(无开销)的字节数(根据 MSDN 文章 估计堆的大小),然后我得到 8087 字节(每页)。

如何在不购买和学习 1000 多页书籍的情况下达到每行 8060 字节(在我的其他问题的答案中提到)和每行 8000 字节(varchar、nvarchar)的限制?

我肯定在存储分配中遗漏了一些东西:要管理的块越少,开销就越大......

Comining from my question "8078 bytes in 8060 B datapage (SQL Server)?" where it was explained to me how to derive 8078 bytes of data per page in MS SQL Server.

If I calculate the number of bytes per page used for data storage (without overhead) of only one row with one column of non-indexed fixed-size type record (as per the MSDN article Estimating the Size of a Heap), then I come to 8087 bytes (per page).

How do I get to to the limits of 8060 bytes per row (mentioned in my other question's answers) and to 8000 bytes per (varchar, nvarchar) without buying and studying 1000+ page books?

I am certainly missing something in storage allocation: the fewer chunks to manage, the more overhead...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

疯狂的代价 2024-10-02 12:08:25

存储引擎内部:剖析一条记录

这是用于SQL Server 2005

  • 记录头
    • 4 字节长
    • 两个字节的记录元数据(记录类型)
    • 记录中向前指向 NULL 位图的两个字节
  • 固定长度部分,包含存储具有固定长度的数据类型的列(例如 bigint、char( 10)、日期时间)
  • NULL 位图
    • 两个字节用于记录中的列数
    • 记录中每列存储一位的可变字节数,无论该列是否可为空(这与 SQL Server 2000 不同且更简单,SQL Server 2000 的每个可为空列仅存储一位)
    • 这允许在读取 NULL 列时进行优化
  • 这允许在读取 NULL可变长度列偏移数组的
    • 两个字节用于可变长度列的计数
    • 每个可变长度列两个字节,给出列值末尾的偏移量
      版本控制标签
  • 仅在 SQL Server 2005 中存在,是一个 14 字节结构,其中包含时间戳和指向 tempdb 中版本存储的指针

因此,对于一个 char(8000)

  • 4 字节(记录头)
  • 8000 固定长度
  • 3 空位图
  • 2可变长度计数字节
  • 14 时间戳

但是,​​如果有 40 varchar(200) 列

  • 4 字节(记录头)
  • 0 固定长度
  • 6 空位图
  • 可变长度计数 2 字节
  • 202 x 40 = 8080
  • 14 时间戳

总计 = 8080 + 4 + 6 + 2 + 14 = 8106。WTF?创建此表时您会收到警告

我不会太在意它:此信息没有日常实用价值

Inside the Storage Engine: Anatomy of a record

This is for SQL Server 2005

  • record header
    • 4 bytes long
    • two bytes of record metadata (record type)
    • two bytes pointing forward in the record to the NULL bitmap
  • fixed length portion of the record, containing the columns storing data types that have fixed lengths (e.g. bigint, char(10), datetime)
  • NULL bitmap
    • two bytes for count of columns in the record
    • variable number of bytes to store one bit per column in the record, regardless of whether the column is nullable or not (this is different and simpler than SQL Server 2000 which had one bit per nullable column only)
    • this allows an optimization when reading columns that are NULL
  • variable-length column offset array
    • two bytes for the count of variable-length columns
    • two bytes per variable length column, giving the offset to the end of the column value
      versioning tag
  • this is in SQL Server 2005 only and is a 14-byte structure that contains a timestamp plus a pointer into the version store in tempdb

So, for one char(8000)

  • 4 bytes (record header)
  • 8000 fixed length
  • 3 null bitmap
  • 2 bytes to count variable-length
  • 14 timestamp

However, if you had 40 varchar(200) columns

  • 4 bytes (record header)
  • 0 fixed length
  • 6 null bitmap
  • 2 bytes to count variable-length
  • 202 x 40 = 8080
  • 14 timestamp

Total = 8080 + 4 + 6 + 2 + 14 = 8106. WTF? You get a warning when you created this table

I would not get too hung up on it: this information has no practical day to day value

擦肩而过的背影 2024-10-02 12:08:25

我不完全确定你在问什么,但如果你的问题是“为什么最大行长度是 8060 字节而不是其他数字?”,或者“为什么 NVARCHAR 的最大长度是 8000 字节?”那么简短的答案是,谁知道呢? (正如 gbn 所说,谁在乎呢?)

所有 MSSQL 限制 - 数据类型大小、最大行大小、每个表的列数、每个索引的列数等 - 只是 Microsoft 的设计决策。我非常确定决策背后有大量的工程文档,但大多数人无法访问这些信息。

如果您对限制是什么、行大小如何计算等具体细节感兴趣,那么阅读 MSSQL 文档是最好的起点。

I'm not totally sure what you're asking, but if your question is "why is the maximum row length 8060 bytes and not some other number?", or "why does NVARCHAR have a maximum length of 8000 bytes?" then the short answer is, who knows? (And as gbn said, who cares?)

All MSSQL limits - data type sizes, maximum row size, columns per table, columns per index etc. - are just design decisions by Microsoft. I'm quite sure that there is a huge amount of engineering documentation behind the decisions, but most people don't have access to that information.

If you're interested in specific details of what the limits are, how row size is calculated etc. then reading the MSSQL documentation is the best place to start.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文