看淡拥有，不刻意追求某些东西，落叶归根，那些属于你的，总会回来。劳动的意义不仅在于追求业绩，更在于完善人的心灵。
这样还能减少CPU缓存命中失效的问题(点击这个链接来查看CPU的缓存是如何工作的以及MESI协议)。下面让我们来揭穿三个有关NULL位图的普遍误区。 误区 #6a:NULL位图并不是任何时候都会用到 正确 就算表中不存在允许NULL的列，NULL位图对于数据行来说会一直存在(数据行指的是堆或是聚集索引的叶子节点)。但对于索引行来说（所谓的索引行也就是聚集索引和非聚集索引的非叶子节点以及非聚集索引的叶子节点）NULL位图就不是一直有效了。 下面这条语句可以有效的证明这一点:
CREATE TABLE NullTest (c1 INT NOT NULL);
CREATE NONCLUSTERED INDEX
NullTest_NC ON NullTest (c1);
GO
INSERT INTO NullTest VALUES (1);
GO
EXEC sp_allocationMetadata 'NullTest';
GO
你可以通过我的博文:Inside The Storage Engine: sp_AllocationMetadata - putting undocumented system catalog views to work.来获得sp_allocationMetadata 的实现脚本。
让我们通过下面的script来分别查看在堆上的页和非聚集索引上的页:
DBCC TRACEON (3604);
DBCC PAGE (foo, 1, 152, 3); -- page ID from SP output
where Index ID = 0
DBCC PAGE (foo, 1, 154, 1); -- page ID from SP output
where Index ID = 2
GO
首先让我们来看堆上这页Dump出来的结果
再来看非聚集索引上的一页Dump出来的结果:
Slot 0 Offset 0x60 Length 11
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Memory Dump
@0x685DC060
误区 #6b: NULL位图仅仅被用于可空列
Slot 0, Offset 0x60, Length 13, DumpStyle BYTE
Record Type = INDEX_RECORD Record Attributes = <<<<<<<
No null bitmap Memory Dump @0x685DC060
错误 当NULL位图存在时，NULL位图会给记录中的每一列对应一位，但是数据库中最小的单位是字节，所以为了向上取整到字节，NULL位图的位数可能会比列数要多。对于这个问题.我已经有一篇博文对此进行概述，请看:Misconceptions around null bitmap size.误区 #6c:给表中添加额外一列时会立即导致SQL Server对表中数据的修改 错误 只有向表中新添加的列是带默认值，且默认值不是NULL时，才会立即导致SQL Server对数据条目进行修改。总之，SQL Server存储引擎会记录一个或多个新添加的列并没有反映在数据记录中。关于这点，我有一篇博文更加深入的对此进行了阐述:Misconceptions around adding columns to a table.
本文SQLServer误区30日谈第6天有关NULL位图的三个误区到此结束。我们都曾经以为，有些事情是不可以放手的。时日渐远，当你回望你会发现，你曾经以为不可以放手的东西，只是生命瞬间的一块跳板。你跳过了，就可以变得更精彩。人在跳板上，最辛苦的不是跳下来那一刻，而是跳下来之前心里的挣扎无助和患得患失。我们以为跳不过去了，闭上眼睛，鼓起勇气，就跳过了。小编再次感谢大家对我们的支持！