我的意思是当数据量大时,需要使用到表分区时,
是用多个文件组,多个文件,以及让它们对应多个磁盘分区,这样效果才好
还是用多个文件组,多个文件,对应一个分区上的不同文件夹,这样是否就起不到作用
或者是多个文件组,多个文件,对应一个磁盘阵列上的多个分区?
使用多个文件跟一个文件,多个文件组跟一个文件组在实现的效果上有无区别?
一般来说,在数据量到多大时,最好使用表分区?
表分区比较适合多大的数据量下使用?
目前,SQL SERVER2005的表分区应用得多不多?效果怎么样.
9 个解决方案
#1
此外,如果有几个大表,是不是不同的表使用不同的表空间,性能更好?
#2
数据量多大用表分区不好说,但是文件的放置最好是分散在各个磁盘上,各个分区上,尤其是数据文件和日志文件不能放一个分区或者磁盘.
#3
谢谢.
假设我有几张大表,那么需要
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
假设我有几张大表,那么需要
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
#4
个人认为以上都是设计优化的一部分 但对于目前的高速Raid阵列来说 对性能的提升或者都看不出来 如果表超过百万以上 DPV会明显一些
#5
几天前就看到这个帖子了，好像没有很多人感兴趣啊。
SQL2005开始有大表分区的功能。简单的说就是把数据切分成多个部分，然后分布到不同的物理位置上。
两种切法：纵向切和横向切。
纵向切的例子是，你有个大表，里面有5年的数据，每年200万条记录，合计1000万条记录，而且每年数据都增加。那么你按年份把大表切成5段，每年一段。这是备份历史数据的好方法。每年的数据放一个段上，新的一年到了，增加一个段到表上，当年数据都写到这个段上。然后把5年前的一个段从表上卸载，保存。以后有用时可以再装回来。
上面的过程说的简单，但是增加和卸载一个段的过程还是比较令人头大的。最好是写成脚本。而且必须修改一个映射函数，保证数据被写到指定的段上。这种方法虽然麻烦，但是比传统的方法（把数据移动到历史表）还是有优点的，尤其是你的表里面数据太多（例如几个G的历史数据），导致移动数据都很慢的时候，甚至不可能的时候。这种方法的优越性就出来了。
横向切的例子是，你的大表是用来做查询的，当然是越快越好。你有4个硬盘，然后你就把数据通过映射函数分布到4个硬盘上，比如按时间切割，每天有6个小时的数据在一个硬盘上。看上去是不错，也的确会快很多。但是存在单点故障，只要任何一个硬盘挂了，你的麻烦就来了。横向切的用法其实就是很原始的磁盘阵列的用法。
如果你很多要速度和可用性的话，还是用RAID吧，RAID5和RAID10（很贵）都比横向切割好得多。
总得来说，大表分区的功能要谨慎使用。我个人觉得横向分布数据不好，很危险，最好用RAID。对于历史数据用纵向分布的方法比较好。
----------------------------------
至于性能嘛，当然是磁盘越多，CPU和内存越多越好，用RAID肯定比一个硬盘快且安全。
另外，你的分区要在不同的物理硬盘上才有意义。如果在一个硬盘的多个逻辑分区上玩表分区就是练练手而已，不会快的。
SQL2005开始有大表分区的功能。简单的说就是把数据切分成多个部分，然后分布到不同的物理位置上。
两种切法：纵向切和横向切。
纵向切的例子是，你有个大表，里面有5年的数据，每年200万条记录，合计1000万条记录，而且每年数据都增加。那么你按年份把大表切成5段，每年一段。这是备份历史数据的好方法。每年的数据放一个段上，新的一年到了，增加一个段到表上，当年数据都写到这个段上。然后把5年前的一个段从表上卸载，保存。以后有用时可以再装回来。
上面的过程说的简单，但是增加和卸载一个段的过程还是比较令人头大的。最好是写成脚本。而且必须修改一个映射函数，保证数据被写到指定的段上。这种方法虽然麻烦，但是比传统的方法（把数据移动到历史表）还是有优点的，尤其是你的表里面数据太多（例如几个G的历史数据），导致移动数据都很慢的时候，甚至不可能的时候。这种方法的优越性就出来了。
横向切的例子是，你的大表是用来做查询的，当然是越快越好。你有4个硬盘，然后你就把数据通过映射函数分布到4个硬盘上，比如按时间切割，每天有6个小时的数据在一个硬盘上。看上去是不错，也的确会快很多。但是存在单点故障，只要任何一个硬盘挂了，你的麻烦就来了。横向切的用法其实就是很原始的磁盘阵列的用法。
如果你很多要速度和可用性的话，还是用RAID吧，RAID5和RAID10（很贵）都比横向切割好得多。
总得来说，大表分区的功能要谨慎使用。我个人觉得横向分布数据不好，很危险，最好用RAID。对于历史数据用纵向分布的方法比较好。
----------------------------------
至于性能嘛，当然是磁盘越多，CPU和内存越多越好，用RAID肯定比一个硬盘快且安全。
另外，你的分区要在不同的物理硬盘上才有意义。如果在一个硬盘的多个逻辑分区上玩表分区就是练练手而已，不会快的。
#6
假设我有几张大表,那么需要
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
----------------------------------------
影响性能的因素按重要程度划分如下：
磁盘I/O速度和带宽 > CPU速度和个数 > 内存速度和大小 > 用户连接数 > 网络速度和带宽 > SQL参数设置
软的方面就多了，比较重要的几个方面按重要程度划分如下：
Database设计 > SQL代码的质量 > 索引的有效性 > 统计数据的有效性
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
----------------------------------------
影响性能的因素按重要程度划分如下：
磁盘I/O速度和带宽 > CPU速度和个数 > 内存速度和大小 > 用户连接数 > 网络速度和带宽 > SQL参数设置
软的方面就多了，比较重要的几个方面按重要程度划分如下：
Database设计 > SQL代码的质量 > 索引的有效性 > 统计数据的有效性
#7
0_0
晕，发现楼主的问题是没分的，我晕倒....
呵呵，无所谓啦
晕，发现楼主的问题是没分的，我晕倒....
呵呵，无所谓啦
#8
3Q.
可能权限不够,点加分提示不能使用此功能:)
对于分区我也担心数据的安全性,
同时更想知道分区的粒度如何设置才好.
如果要根据几个列分区,
还只能增加一列,把表达式的值写入此列,
然后再按此列进行分区
可能权限不够,点加分提示不能使用此功能:)
对于分区我也担心数据的安全性,
同时更想知道分区的粒度如何设置才好.
如果要根据几个列分区,
还只能增加一列,把表达式的值写入此列,
然后再按此列进行分区
#9
接分是王道！
#1
此外,如果有几个大表,是不是不同的表使用不同的表空间,性能更好?
#2
数据量多大用表分区不好说,但是文件的放置最好是分散在各个磁盘上,各个分区上,尤其是数据文件和日志文件不能放一个分区或者磁盘.
#3
谢谢.
假设我有几张大表,那么需要
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
假设我有几张大表,那么需要
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
#4
个人认为以上都是设计优化的一部分 但对于目前的高速Raid阵列来说 对性能的提升或者都看不出来 如果表超过百万以上 DPV会明显一些
#5
几天前就看到这个帖子了，好像没有很多人感兴趣啊。
SQL2005开始有大表分区的功能。简单的说就是把数据切分成多个部分，然后分布到不同的物理位置上。
两种切法：纵向切和横向切。
纵向切的例子是，你有个大表，里面有5年的数据，每年200万条记录，合计1000万条记录，而且每年数据都增加。那么你按年份把大表切成5段，每年一段。这是备份历史数据的好方法。每年的数据放一个段上，新的一年到了，增加一个段到表上，当年数据都写到这个段上。然后把5年前的一个段从表上卸载，保存。以后有用时可以再装回来。
上面的过程说的简单，但是增加和卸载一个段的过程还是比较令人头大的。最好是写成脚本。而且必须修改一个映射函数，保证数据被写到指定的段上。这种方法虽然麻烦，但是比传统的方法（把数据移动到历史表）还是有优点的，尤其是你的表里面数据太多（例如几个G的历史数据），导致移动数据都很慢的时候，甚至不可能的时候。这种方法的优越性就出来了。
横向切的例子是，你的大表是用来做查询的，当然是越快越好。你有4个硬盘，然后你就把数据通过映射函数分布到4个硬盘上，比如按时间切割，每天有6个小时的数据在一个硬盘上。看上去是不错，也的确会快很多。但是存在单点故障，只要任何一个硬盘挂了，你的麻烦就来了。横向切的用法其实就是很原始的磁盘阵列的用法。
如果你很多要速度和可用性的话，还是用RAID吧，RAID5和RAID10（很贵）都比横向切割好得多。
总得来说，大表分区的功能要谨慎使用。我个人觉得横向分布数据不好，很危险，最好用RAID。对于历史数据用纵向分布的方法比较好。
----------------------------------
至于性能嘛，当然是磁盘越多，CPU和内存越多越好，用RAID肯定比一个硬盘快且安全。
另外，你的分区要在不同的物理硬盘上才有意义。如果在一个硬盘的多个逻辑分区上玩表分区就是练练手而已，不会快的。
SQL2005开始有大表分区的功能。简单的说就是把数据切分成多个部分，然后分布到不同的物理位置上。
两种切法：纵向切和横向切。
纵向切的例子是，你有个大表，里面有5年的数据，每年200万条记录，合计1000万条记录，而且每年数据都增加。那么你按年份把大表切成5段，每年一段。这是备份历史数据的好方法。每年的数据放一个段上，新的一年到了，增加一个段到表上，当年数据都写到这个段上。然后把5年前的一个段从表上卸载，保存。以后有用时可以再装回来。
上面的过程说的简单，但是增加和卸载一个段的过程还是比较令人头大的。最好是写成脚本。而且必须修改一个映射函数，保证数据被写到指定的段上。这种方法虽然麻烦，但是比传统的方法（把数据移动到历史表）还是有优点的，尤其是你的表里面数据太多（例如几个G的历史数据），导致移动数据都很慢的时候，甚至不可能的时候。这种方法的优越性就出来了。
横向切的例子是，你的大表是用来做查询的，当然是越快越好。你有4个硬盘，然后你就把数据通过映射函数分布到4个硬盘上，比如按时间切割，每天有6个小时的数据在一个硬盘上。看上去是不错，也的确会快很多。但是存在单点故障，只要任何一个硬盘挂了，你的麻烦就来了。横向切的用法其实就是很原始的磁盘阵列的用法。
如果你很多要速度和可用性的话，还是用RAID吧，RAID5和RAID10（很贵）都比横向切割好得多。
总得来说，大表分区的功能要谨慎使用。我个人觉得横向分布数据不好，很危险，最好用RAID。对于历史数据用纵向分布的方法比较好。
----------------------------------
至于性能嘛，当然是磁盘越多，CPU和内存越多越好，用RAID肯定比一个硬盘快且安全。
另外，你的分区要在不同的物理硬盘上才有意义。如果在一个硬盘的多个逻辑分区上玩表分区就是练练手而已，不会快的。
#6
假设我有几张大表,那么需要
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
----------------------------------------
影响性能的因素按重要程度划分如下：
磁盘I/O速度和带宽 > CPU速度和个数 > 内存速度和大小 > 用户连接数 > 网络速度和带宽 > SQL参数设置
软的方面就多了，比较重要的几个方面按重要程度划分如下：
Database设计 > SQL代码的质量 > 索引的有效性 > 统计数据的有效性
1,把数据文件和日志文件分区存放
2,需要把数据表和索引分区存放
3,需要把不同的大表分区存放
4,需要把每个大表按分区策略分区存放
5,同时需要使用磁盘阵列,多CPU
以上哪几个措施对性能的影响更大?
还有哪些可以考虑提升的空间啊.
----------------------------------------
影响性能的因素按重要程度划分如下：
磁盘I/O速度和带宽 > CPU速度和个数 > 内存速度和大小 > 用户连接数 > 网络速度和带宽 > SQL参数设置
软的方面就多了，比较重要的几个方面按重要程度划分如下：
Database设计 > SQL代码的质量 > 索引的有效性 > 统计数据的有效性
#7
0_0
晕，发现楼主的问题是没分的，我晕倒....
呵呵，无所谓啦
晕，发现楼主的问题是没分的，我晕倒....
呵呵，无所谓啦
#8
3Q.
可能权限不够,点加分提示不能使用此功能:)
对于分区我也担心数据的安全性,
同时更想知道分区的粒度如何设置才好.
如果要根据几个列分区,
还只能增加一列,把表达式的值写入此列,
然后再按此列进行分区
可能权限不够,点加分提示不能使用此功能:)
对于分区我也担心数据的安全性,
同时更想知道分区的粒度如何设置才好.
如果要根据几个列分区,
还只能增加一列,把表达式的值写入此列,
然后再按此列进行分区
#9
接分是王道！