读取固定长度数据类型

Question

假设我有一个固定长度的列，我SELECT从中获取 100 行。当读取固定长度列的不同行时，SQL Server 是否检查每一行的列长度，还是检查一次并重用此信息，以便可以更快地读取后续行？

相反，对于可变长度列，SQL Server 需要使用偏移数组检查每行的每个可变长度列的长度。

所以我的问题是：SQL Server 是否检查每行的固定长度数据类型的长度（即在该行的状态位 A 和 B 部分之后）？从逻辑上讲，当它需要读取固定长度列时，只需要检查一次。

这种开销是索引最适合固定长度列的原因吗？

不试图解决任何问题，只是试图理解。

额外信息：关于索引最好在固定长度列上：当我阅读这篇文章“ SQL Server 性能的索引策略”时，整个问题就开始了。在某一时刻，它说：“聚集索引键应该很窄，但也使用固定宽度的数据类型。” 这一说法的理由是什么？我只能想到与我的问题相关的原因，即固定长度的列读取起来更便宜，因为长度只需要检查一次。

Answer 1

在FixedVar存储格式中，每个固定长度列在每行中以相同的偏移量出现。

SQL Server 缓存所需的每个固定长度列的偏移量，并在后续行访问时重用该信息。它不会重新计算每行的偏移量。

因此，与读取可变长度数据相比，从行的固定长度部分访问数据具有较小的效率优势。它并不像您想象的那么多，因为查找可变长度数据只涉及对很可能已经在 L1 缓存中的数据执行几个额外的 CPU 指令（尽管不一定在同一行）。

如果您测试访问固定存储和可变存储中的大量相同数据，您可能能够测量到微小的差异。我还没有在现代硬件上看到任何最新结果。一般来说，还有与行模式查询执行相关的其他开销，我预计这些开销会压倒这种影响。

总之：我不会特意选择固定长度类型而不是可变长度类型。选择最适合当前应用程序的数据类型。

这种开销是索引在固定长度列上最好的原因吗？

辅助 B 树索引是一个单独的结构，其中包含根据索引键排序的索引数据的副本。上面提到的一般注意事项同样适用于从索引页读取数据和从数据页读取数据。

“聚集索引键应该很窄，但也使用固定宽度的数据类型。”

辅助 B 树索引必须包含行定位符（聚集索引键和可能的唯一符）。当聚集索引键包括可变长度数据类型时，任何辅助b树索引行可能具有可变长度列数和可变列偏移数组的额外开销。因此，二级索引可能比它们需要的要宽一些。我相信这就是保罗·兰德尔在那句话中提到的要点。