因胸联盟 发表于 2015-1-16 20:10:50

绝无经由的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则更倾向于垂直可扩展性。

灵魂腐蚀 发表于 2015-1-17 14:37:35

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

柔情似水 发表于 2015-1-20 19:53:11

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

变相怪杰 发表于 2015-1-29 19:17:29

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

小女巫 发表于 2015-2-6 03:24:35

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

不帅 发表于 2015-2-15 10:44:23

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

透明 发表于 2015-3-4 11:26:43

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

莫相离 发表于 2015-3-11 19:03:34

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

蒙在股里 发表于 2015-3-19 08:58:33

光写几个SQL实在叫无知。

深爱那片海 发表于 2015-3-27 18:24:35

理解了存储结构,再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识
页: [1]
查看完整版本: 绝无经由的SQL Server 数据存储与 NTFS 簇的巨细