对于一般的INT、char、tinyint等数据类型，他们占用的存储空间都是以Byte字节为单位的，但是BIT类型由于只有0和1或者说false和true，这种情况只需要一个Bit位就可以表示了，那么在SQL Server中BIT类型到底占用了多少空间?是不是由一个Bit位来存储的?或者可能是使用一个字节来存储的?

　　这两个答案都不正确!实际上BIT类型占用的空间与BIT类型的列所在表的位置有关，有些情况下BIT占用了一个字节，有些情况下BIT实际占用了几个位(几个BIT类型的列共用一个字节)。下面就来具体分析一下：

　　1. 单独的BIT类型的列将占用一个字节。

          所谓单独就是指一个BIT类型的列的左边定长列和右边定长列都不是BIT类型的列。例如这样一个表： 

create TABLE tt  　　(  　　c1 INT PRIMARY KEY,  　　c2 BIT NOT NULL,  　　c3 char(2) NOT NULL  　　)

     SQL Server在存储表中的数据时先是将表中的列按照原有顺序分为定长和变长(变长就是长度不固定的数据类型，如varchar,nvarchar,varbinary等)两组。在数据页中存储数据时先存储所有定长的数据，然后再存储变长的数据。这里由于c2列的左边是int类型，右边是char类型，都是定长的，而且不是BIT类型，所以c1和c3之间必须留出一个字节来存储c2，虽然c2只用到了其中的一个位。

　　下面我们来验证一下是否真是如我所说：

　　(1)插入一行数据：

insert INTO tt VALUES(1,1,’aa’)

　　(2)找到tt表数据的第一页(也就是刚才插入的这行数据所在页)的文件号和页面号：   

select first_page  　　FROM sys.partitions p  　　INNER join sys.system_internals_allocation_units a  　　ON p.partition_id=a.container_id  　　where OBJECT_ID= OBJECT_ID(’dbo.tt’)

　　我这里返回的是0x76 00 00 00 01 00，这里需要反转过来看0x00 01 00 00 00 76。其中前两个字节是文件号，后面的是页面号，所以文件号是1，页面号是118(0x76转换成十进制就是118)

　　(3)使用DBCC page命令查看该页的内部结构：   

DBCC traceon(3604)  　　DBCC page(TestDB,1,118,3)

　　这儿DBCC traceon(3604)表示将页面内容直接输出，TestDB是我创建的tt表所在的数据库，1和118前面已经说了。最后一个是打印选项。0表示只输出页头;1则不会输出所有内容，只是输出有数据的内容;2表示完整的输出这个页的内容，3则和1差不多，但是要每条记录分别列出列的值。以下是输出的需要关注的内容

00000000: 10000b00 01000000 01616103 0000………aa…

　　关于数据行的具体格式我就不在这里多说了，在《SQL Server 2005技术内幕 存储引擎》中有详细介绍。我们插入的数据从第5个字节开始，是01000000 016161。这儿01000000就是c1，由于是int类型，所以占用4个字节。接下来01就是c2，在这里占用了1字节。再接下来6161就是c3了。