绝无经由的SQL Server 数据存储与 NTFS 簇的巨细

对于IT经理来说，令他们喜欢的MySQL的简单性还有另一方面。MySQL可以运行的更快速。某些人或许会说MySQL缺少了一些人们想要的功能。起首感激微软创造的NTFS文件体系，的确长短常强健的文件体系，功效壮大。

簇是磁盘举行I/O读写时的最基础单元（就是NTFS中的分派单位）。

明天来讲一下在SQLServer的数据存储中与NTFS簇巨细有关的话题。NTFS在凌驾2GB的分区中，格局化时会默许利用4KB的簇，这基础上就成了如今年夜部分硬盘的簇巨细。在簇不年夜于4KB时，可使用碎片收拾。

NTFS簇巨细能够设置成从512B~64KB巨细，固然必需在格局化时指定，不然就不成以变动了。簇太小，空间使用率高，但分区表较年夜，碎片多，功能较差；簇太年夜，空间使用率低，但碎片少，功能较好。因而4KB可谓是广泛的选择。

如今的硬盘，动则容量几百GB，空间仿佛已不再是成绩。但磁盘的I/O一向是功能的瓶颈，为了进步磁盘读写速度，列位可谓是挖空心思了。不管怎样，硬盘只需选用了，改动它的物理计划仿佛其实不太大概，也不保举如许做，因而就只能从别的的中央动手了，办法如用RAID摆设了、常常地收拾碎片、用好的芯片、用好的数据线了等等，能用的都用了。

SQLServer服务器是对I/O请求高的使用，它的数据文件读写基础单元是页，每页的巨细是8KB，一连的8个页构成一个区，也就是64KB的区，且一样平常数据文件都对照年夜，一样平常临盆情况中，几GB以上是罕见的。而且基础上不会有人在SQLServer的存储上用碎片收拾了，因而我们能够将公用于SQLServer存储的磁盘分区格局化成为64KB的簇，如许在不华侈空间的条件下，又能够进步功能。

有无风险？固然有了，在磁盘呈现劫难时，丢的数据大概就会多一点，起码会丢64KB了，不外理论证实这类计划仍是十分可行的，由于一样平常服务器的RAID摆设分块也是64KB，两个都是64KB，就无所谓了。

别的使用场景列位也能够参考，不合错误的地方，接待品评。

本文gytnet

本文出处：http://www.ckuyun.com/gytnet/archive/2009/12/21/1628561.html

关于这个理由我把它放在最后一位。在很多业界专家中有一个相当一致的观点：MySQL不能很好的扩展。关于这点可能有很大的分歧，争论的焦点主要集中于水平可扩展性和垂直可扩展性上。MySQL则更倾向于垂直可扩展性。

无法深入到数据库系统层面去了解和探究

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）

sqlserver的痛苦之处在于有用文档的匮乏，很多只是表明的东西

很多书籍啊，不过个人认为看书太慢，还不如自己学。多做实际的东西，就会遇到很多问题，网上搜下解决问题。不断重复这个过程，在配合sql的F1功能。

作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

理解了存储结构，再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识

光写几个SQL实在叫无知。

理解了存储结构，再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识