增加文件组(表分区)会提高性能吗?有做过的进

duanzhi1984 2014-05-12 11:34:28
表中有200万条数据,想办法,把部分数据按时间分区,将增加多个文件组,做成表分区。
多个文件组中的文件还是在一个磁盘上,是否对性能有所提高 。
(前提,不移动旧数据到其他表中,分区后,依然有200万)
...全文
506 19 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
19 条回复
切换为时间正序
请发表友善的回复…
发表回复
牛牛牛丶 2016-02-03
  • 打赏
  • 举报
回复
赞同分区是提高磁盘IO来对速度提高的说法,如果在同意磁盘上,数据量小了是看不出来效果,个人认为分区的主要目的还是大数据的维护做贡献。
山寨DBA 2014-05-15
  • 打赏
  • 举报
回复
引用 17 楼 duanzhi1984 的回复:
有没有测试当查跨分区与查询同一个分区时的区别
这个木有嗫。。。自己测试一下呗
duanzhi1984 2014-05-15
  • 打赏
  • 举报
回复
引用 12 楼 hwhmh2010 的回复:
看了你们说的,难道是因为我测试的数据量500W太少了。。。 我当时测试的结果就是:如果分区表不使用多文件多磁盘,而是和普通未分区表一样放在同一个磁盘同一个文件组同一个文件的话,性能确实没有太大提高,就一点点。。。如果是分磁盘存放就会有提高。。。 [quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
引用 8 楼 wufeng4552 的回复:
[quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升 [/quote]
引用 9 楼 x_wy46 的回复:
[quote=引用 8 楼 wufeng4552 的回复:] [quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升 [/quote] 分区后除了B树的深度(由根节点到叶节点的高度)降低以减少数据查询的IO之外, 分区之后分区内的数据的增删查改,只影响当前分区的增删查改, 分区之后事实上就是分区内的B树, 系统维护单独的B树的平衡结构的代价也会比整棵B树的代价小、 当然这个我也没有一个明确的测试结果,根据理论猜测的[/quote]
引用 10 楼 sz_haitao 的回复:
[quote=引用 5 楼 hwhmh2010 的回复:] [quote=引用 4 楼 sz_haitao 的回复:] 200W,不算大 再大了,改为 分区表 就行了,即使同一个文件、同一个磁盘,索引合理,效率都会好很多 再大,多磁盘了,再考虑分多个文件,分散到不同盘
即使同一个文件、同一个磁盘,索引合理,效率都会好很多-------这个观点我不晓得大家是怎么的出来的,有自己做过测试吗? 大哥们,分区表为什么会提高性能?提高的是那一块?大家有研究过吗? 我要说的是:同一个文件、同一个磁盘,在相同索引和硬件的前提下,性能基本没有提升。只要你没分区的表的索引是跟分区后的表的索引是一样的,就没有多大差异-----针对是否相同磁盘,相同文件的分区表问题,我测试过500W的数据[/quote] 我现在一个系统的一个表快10亿条(975362356)了,分100个区,没任何问题。。。。 分区表,如果分区规则恰当,任何増删改都只涉及1/100的记录(数据页、索引维护。。。。),即使需要跨分区查询,也是可以并行进行! 一般单个sql很难利用满16个核心,但是对分区表的查询,就能充分利用多核[/quote][/quote] 有没有测试当查跨分区与查询同一个分区时的区别
duanzhi1984 2014-05-15
  • 打赏
  • 举报
回复
引用 10 楼 sz_haitao 的回复:
[quote=引用 5 楼 hwhmh2010 的回复:] [quote=引用 4 楼 sz_haitao 的回复:] 200W,不算大 再大了,改为 分区表 就行了,即使同一个文件、同一个磁盘,索引合理,效率都会好很多 再大,多磁盘了,再考虑分多个文件,分散到不同盘
即使同一个文件、同一个磁盘,索引合理,效率都会好很多-------这个观点我不晓得大家是怎么的出来的,有自己做过测试吗? 大哥们,分区表为什么会提高性能?提高的是那一块?大家有研究过吗? 我要说的是:同一个文件、同一个磁盘,在相同索引和硬件的前提下,性能基本没有提升。只要你没分区的表的索引是跟分区后的表的索引是一样的,就没有多大差异-----针对是否相同磁盘,相同文件的分区表问题,我测试过500W的数据[/quote] 我现在一个系统的一个表快10亿条(975362356)了,分100个区,没任何问题。。。。 分区表,如果分区规则恰当,任何増删改都只涉及1/100的记录(数据页、索引维护。。。。),即使需要跨分区查询,也是可以并行进行! 一般单个sql很难利用满16个核心,但是对分区表的查询,就能充分利用多核[/quote] 能说下你数据库系统的配置吗?
發糞塗牆 2014-05-13
  • 打赏
  • 举报
回复
要做多文件组,最好分到多个物理磁盘,不然性能没什么提高
山寨DBA 2014-05-13
  • 打赏
  • 举报
回复
好吧,看来需要学习的真的还很多很多
haitao 2014-05-13
  • 打赏
  • 举报
回复
能充分利用多核,对于效率也是很大的提高,如果数据都已经在内存了 这一点,3.x和4.x的winrar,对比就很明显 后者能利用多核,压缩速度就明显比前者提高很多。。。。
發糞塗牆 2014-05-13
  • 打赏
  • 举报
回复
也不能这样说,500W可以用来模拟一下分区的特性和一些内部机制,只是500W还不到做分区的地步而已。
引用 12 楼 hwhmh2010 的回复:
看了你们说的,难道是因为我测试的数据量500W太少了。。。 我当时测试的结果就是:如果分区表不使用多文件多磁盘,而是和普通未分区表一样放在同一个磁盘同一个文件组同一个文件的话,性能确实没有太大提高,就一点点。。。如果是分磁盘存放就会有提高。。。 [quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
引用 8 楼 wufeng4552 的回复:
[quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升 [/quote]
引用 9 楼 x_wy46 的回复:
[quote=引用 8 楼 wufeng4552 的回复:] [quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升 [/quote] 分区后除了B树的深度(由根节点到叶节点的高度)降低以减少数据查询的IO之外, 分区之后分区内的数据的增删查改,只影响当前分区的增删查改, 分区之后事实上就是分区内的B树, 系统维护单独的B树的平衡结构的代价也会比整棵B树的代价小、 当然这个我也没有一个明确的测试结果,根据理论猜测的[/quote]
引用 10 楼 sz_haitao 的回复:
[quote=引用 5 楼 hwhmh2010 的回复:] [quote=引用 4 楼 sz_haitao 的回复:] 200W,不算大 再大了,改为 分区表 就行了,即使同一个文件、同一个磁盘,索引合理,效率都会好很多 再大,多磁盘了,再考虑分多个文件,分散到不同盘
即使同一个文件、同一个磁盘,索引合理,效率都会好很多-------这个观点我不晓得大家是怎么的出来的,有自己做过测试吗? 大哥们,分区表为什么会提高性能?提高的是那一块?大家有研究过吗? 我要说的是:同一个文件、同一个磁盘,在相同索引和硬件的前提下,性能基本没有提升。只要你没分区的表的索引是跟分区后的表的索引是一样的,就没有多大差异-----针对是否相同磁盘,相同文件的分区表问题,我测试过500W的数据[/quote] 我现在一个系统的一个表快10亿条(975362356)了,分100个区,没任何问题。。。。 分区表,如果分区规则恰当,任何増删改都只涉及1/100的记录(数据页、索引维护。。。。),即使需要跨分区查询,也是可以并行进行! 一般单个sql很难利用满16个核心,但是对分区表的查询,就能充分利用多核[/quote][/quote]
山寨DBA 2014-05-13
  • 打赏
  • 举报
回复
看了你们说的,难道是因为我测试的数据量500W太少了。。。 我当时测试的结果就是:如果分区表不使用多文件多磁盘,而是和普通未分区表一样放在同一个磁盘同一个文件组同一个文件的话,性能确实没有太大提高,就一点点。。。如果是分磁盘存放就会有提高。。。
引用 7 楼 DBA_Huangzj 的回复:
分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
引用 8 楼 wufeng4552 的回复:
[quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升 [/quote]
引用 9 楼 x_wy46 的回复:
[quote=引用 8 楼 wufeng4552 的回复:] [quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升 [/quote] 分区后除了B树的深度(由根节点到叶节点的高度)降低以减少数据查询的IO之外, 分区之后分区内的数据的增删查改,只影响当前分区的增删查改, 分区之后事实上就是分区内的B树, 系统维护单独的B树的平衡结构的代价也会比整棵B树的代价小、 当然这个我也没有一个明确的测试结果,根据理论猜测的[/quote]
引用 10 楼 sz_haitao 的回复:
[quote=引用 5 楼 hwhmh2010 的回复:] [quote=引用 4 楼 sz_haitao 的回复:] 200W,不算大 再大了,改为 分区表 就行了,即使同一个文件、同一个磁盘,索引合理,效率都会好很多 再大,多磁盘了,再考虑分多个文件,分散到不同盘
即使同一个文件、同一个磁盘,索引合理,效率都会好很多-------这个观点我不晓得大家是怎么的出来的,有自己做过测试吗? 大哥们,分区表为什么会提高性能?提高的是那一块?大家有研究过吗? 我要说的是:同一个文件、同一个磁盘,在相同索引和硬件的前提下,性能基本没有提升。只要你没分区的表的索引是跟分区后的表的索引是一样的,就没有多大差异-----针对是否相同磁盘,相同文件的分区表问题,我测试过500W的数据[/quote] 我现在一个系统的一个表快10亿条(975362356)了,分100个区,没任何问题。。。。 分区表,如果分区规则恰当,任何増删改都只涉及1/100的记录(数据页、索引维护。。。。),即使需要跨分区查询,也是可以并行进行! 一般单个sql很难利用满16个核心,但是对分区表的查询,就能充分利用多核[/quote]
山寨DBA 2014-05-13
  • 打赏
  • 举报
回复
haitao 2014-05-13
  • 打赏
  • 举报
回复
引用 5 楼 hwhmh2010 的回复:
[quote=引用 4 楼 sz_haitao 的回复:] 200W,不算大 再大了,改为 分区表 就行了,即使同一个文件、同一个磁盘,索引合理,效率都会好很多 再大,多磁盘了,再考虑分多个文件,分散到不同盘
即使同一个文件、同一个磁盘,索引合理,效率都会好很多-------这个观点我不晓得大家是怎么的出来的,有自己做过测试吗? 大哥们,分区表为什么会提高性能?提高的是那一块?大家有研究过吗? 我要说的是:同一个文件、同一个磁盘,在相同索引和硬件的前提下,性能基本没有提升。只要你没分区的表的索引是跟分区后的表的索引是一样的,就没有多大差异-----针对是否相同磁盘,相同文件的分区表问题,我测试过500W的数据[/quote] 我现在一个系统的一个表快10亿条(975362356)了,分100个区,没任何问题。。。。 分区表,如果分区规则恰当,任何増删改都只涉及1/100的记录(数据页、索引维护。。。。),即使需要跨分区查询,也是可以并行进行! 一般单个sql很难利用满16个核心,但是对分区表的查询,就能充分利用多核
专注or全面 2014-05-13
  • 打赏
  • 举报
回复
引用 8 楼 wufeng4552 的回复:
[quote=引用 7 楼 DBA_Huangzj 的回复:] 分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升 [/quote] 分区后除了B树的深度(由根节点到叶节点的高度)降低以减少数据查询的IO之外, 分区之后分区内的数据的增删查改,只影响当前分区的增删查改, 分区之后事实上就是分区内的B树, 系统维护单独的B树的平衡结构的代价也会比整棵B树的代价小、 当然这个我也没有一个明确的测试结果,根据理论猜测的
水族杰纶 2014-05-13
  • 打赏
  • 举报
回复
引用 7 楼 DBA_Huangzj 的回复:
分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
我也说说我的理解吧,如果理解的不对,请指正 1)分区可以将一个逻辑的表在物理上划分成多个 当然楼主这个只有一个物理磁盘,达不到这个目的IO性能可能提高不了 2)一个分区就是一个B-Tree或者堆,如果一个表不做分区这个B-Tree可能就灰常大,层次就比较深,相反每个分区的B-Tree 就小的多,如果查询正好落在一个分区或者少数的分区内,这个性能会有提升
發糞塗牆 2014-05-13
  • 打赏
  • 举报
回复
分区的确是通过增大并行IO来提高性能,如果分区都在多个盘符但是这些盘符实际上是一个物理磁盘,不保证没效果,但是估计效果不明显,另外分区就是通过把大区(没分区的表)水平切割成多个区的方式来减少需要访问的范围从而提高性能。曾经看过一篇文章,不记得是不是微软的,说3000W以上才建议用分区。 目前还处于小打小闹,没有真正大规模应用,当年1T的库又是2000的,没机会试,等我搞到这块的时候再发文
山寨DBA 2014-05-13
  • 打赏
  • 举报
回复
引用 1 楼 DBA_Huangzj 的回复:
要做多文件组,最好分到多个物理磁盘,不然性能没什么提高
黄哥,我刚才5#说的对么。。。 反正我当时在同一台服务器上测试的时候是那个结果呢。。。 我觉得分区表提升性能主要是通过提高物理IO来实现的,然后就是管理起来比较方便。
山寨DBA 2014-05-13
  • 打赏
  • 举报
回复
引用 4 楼 sz_haitao 的回复:
200W,不算大 再大了,改为 分区表 就行了,即使同一个文件、同一个磁盘,索引合理,效率都会好很多 再大,多磁盘了,再考虑分多个文件,分散到不同盘
即使同一个文件、同一个磁盘,索引合理,效率都会好很多-------这个观点我不晓得大家是怎么的出来的,有自己做过测试吗? 大哥们,分区表为什么会提高性能?提高的是那一块?大家有研究过吗? 我要说的是:同一个文件、同一个磁盘,在相同索引和硬件的前提下,性能基本没有提升。只要你没分区的表的索引是跟分区后的表的索引是一样的,就没有多大差异-----针对是否相同磁盘,相同文件的分区表问题,我测试过500W的数据
haitao 2014-05-13
  • 打赏
  • 举报
回复
200W,不算大 再大了,改为 分区表 就行了,即使同一个文件、同一个磁盘,索引合理,效率都会好很多 再大,多磁盘了,再考虑分多个文件,分散到不同盘
专注or全面 2014-05-13
  • 打赏
  • 举报
回复
你200W数据,怎么分区,分区能不能提高性能,能提高多少性能,这个不好下结论,我估计不能,200W数据没必要到分区的那个程度 分区就是将不同的数据逻辑上分开存储,当然也可以同时在物理上也分开存储,如果物理上没有分开存储,也就是说不同的逻辑存储单元位于同一个物理磁盘上,能不能提高性能? 我觉得能,就好比从1亿条数据中找出一条数据,同等条件下,跟从分区后的1000万数据中找出一条数据,你说哪个代价大? 当然我不是否定没必要从物理上分开存储 空口五凭,楼主可以参考如下链接,也可以自己从各个方面测试测试 http://blog.csdn.net/szstephenzhou/article/details/7788787
山寨DBA 2014-05-13
  • 打赏
  • 举报
回复
仅仅是增加文件组,但是文件组对应的文件却放在相同的磁盘的话性能提高不了。。。 表分区提高性能的前提是不同的分区放在不同的磁盘上,通过提高IO来通过性能的

22,302

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧