绝无经由的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有个清晰地认识
页:
[1]