首先感謝微軟發明的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