首先感谢微软发明的NTFS文件系统，确实是非常健壮的文件系统，功能强大。
簇是磁盘进行I/O读写时的最基本单位（就是NTFS中的分配单元）。
今天来说一下在SQL Server的数据存储中与NTFS簇大小有关的话题。NTFS在超过2GB的分区中，格式化时会默认使用4KB的簇，这基本上就成了现在大部分硬盘的簇大小。在簇不大于4KB时，可以使用碎片整理。
NTFS簇大小可以设置成从512B~64KB大小，当然必须在格式化时指定，否则就不可以更改了。簇太小，空间利用率高，但分区表较大，碎片多，性能较差；簇太大，空间利用率低，但碎片少，性能较好。于是4KB可谓是普遍的选择。
现在的硬盘，动则容量几百GB，空间似乎已经不再是问题。但磁盘的I/O一直是性能的瓶颈，为了提高磁盘读写速率，各位可谓是绞尽脑汁了。无论如何，硬盘只要选用了，改变它的物理设计似乎并不太可能，也不推荐这样做，于是就只能从其它的地方着手了，方法如用RAID陈列了、经常地整理碎片、用好的芯片、用好的数据线了等等，能用的都用了。
SQL Server服务器是对I/O要求高的应用，它的数据文件读写基本单位是页，每页的大小是8KB，连续的8个页组成一个区，也就是64KB的区，且一般数据文件都比较大，一般生产环境中，几GB以上是常见的。并且基本上不会有人在SQL Server的存储上用碎片整理了，因此我们可以将专用于SQL Server存储的磁盘分区格式化成为64KB的簇，这样在不浪费空间的前提下，又可以提高性能。
有没有风险？当然有了，在磁盘出现灾难时，丢的数据可能就会多一点，最少会丢64KB了，不过实践证明这种方案还是非常可行的，因为一般服务器的RAID陈列分块也是64KB，两个都是64KB，就无所谓了。
其它应用场景各位也可以参考，不对之处，欢迎批评。
本文作者：gytnet
本文出处：http://www.cnblogs.com/gytnet/archive/2009/12/21/1628561.htm