讀取固定長度數據類型
假設我有一個固定長度的列，我
SELECT從它開始，比如 100 行。在讀取固定長度列的不同行時，SQL Server 是檢查每一行的列長度還是檢查一次並重用此資訊以便可以更快地讀取後續行？相反，對於可變長度列，SQL Server 需要使用偏移數組檢查每一行的每個可變長度列的長度。
所以我的問題是：SQL Server 是否檢查每一行的固定長度數據類型的長度（即在行的狀態位 A 和 B 部分之後）？從邏輯上講，當它需要讀取一個固定長度的列時，它只需要檢查一次。
這是為什麼索引最適合固定長度列的原因嗎？
不試圖解決任何問題，只是試圖理解。
額外資訊：關於固定長度列上的索引最好：當我閱讀這篇文章SQL Server 性能的索引策略時，這整個問題就開始了。有一次它說：“聚集索引鍵應該很窄，但也應該使用固定寬度的數據類型。” 這種說法的原因是什麼？我只能想到與我的問題有關的原因，即固定長度的列更便宜，因為長度只需要檢查一次。
在FixedVar儲存格式中，每個定長列在每一行中出現在相同的偏移量處。
SQL Server 記憶體所需的每個固定長度列的偏移量，並在後續行訪問中重用該資訊。它不會為每一行重新計算偏移量。
因此，從行的固定長度部分訪問數據與讀取可變長度數據相比具有較小的效率優勢。這並不像您想像的那麼多，因為查找可變長度數據只涉及對很可能已經在 L1 高速記憶體中的數據的幾個額外 CPU 指令（儘管不一定在同一行）。
如果您測試在固定和可變儲存中訪問大量相同的數據，您可能能夠測量出微小的差異。我還沒有看到任何關於現代硬體的最新結果。通常還有其他與行模式查詢執行相關的成本，我預計這些成本會超過這種效果。
總結：我不會特意選擇固定長度類型而不是可變長度類型。選擇最適合手頭應用程序的數據類型。
這是為什麼索引最適合固定長度列的原因嗎？
二級 b 樹索引是一個單獨的結構，其中包含根據索引鍵排序的索引數據的副本。上述相同的一般注意事項適用於從索引頁讀取數據和從數據頁讀取數據。
“聚集索引鍵應該很窄，但也應該使用固定寬度的數據類型。”
二級 b 樹索引必須包括行定位符（聚集索引鍵和可能的唯一符）。當聚集索引鍵包含可變長度數據類型時，任何二級 b 樹索引行可能對可變長度列的數量和可變列偏移數組有額外的成本。因此，二級索引可能比它們需要的要寬一些。我相信這就是保羅蘭德爾在這句話中所暗示的觀點。