目前做法是 按照FID 进行分区，1,30w, 30w到60w, 60w到90w， 相当于1年12个分区，10年就120个分区，
感觉现在做法有2个不好：
1 分区太多了，以后好难维护
2 只有最近3个月数据才经常被访问，其他都是历史数据，创建那么多分区完全是多余。
本来是想建立4个分区， 最近1个月，最近2个月，最近3个月，其他所有的。 但是这个时间不好定义，因为时间是一直在变化的，确定不了范围，所以采用了FID分区，但是FID 也是在不停的增长，做了建立了好多空的分区。
大家有什么好的建议?
33 个解决方案
#1
几十万一个分区不多，2008R2都能支持到15000个分区了。另外最近3个月才频繁的话，前面三个月可以通过分区switch，移到一个大的只读文件组上的分区中。如何分区要视乎查询所用，你所说的“xx月”，应该优先考虑以时间来做分区列
#2
还有 个问题， 如果 分区都放在一个primary 文件组， 和 放在多个 文件组 里面有什么区别?
#3
1、管理上不方便。说白了就是牵一发动全身。
2、多个文件组如果放在不同的物理磁盘，并且分区对齐、磁盘配置合理的话，能够加大并行读取
2、多个文件组如果放在不同的物理磁盘，并且分区对齐、磁盘配置合理的话，能够加大并行读取
#4
你所说的“xx月”，应该优先考虑以时间来做分区列
这个时间是变化的，一直往后增加，这个怎么确定，
例如 现在是 201407月份，那么最近三个月201407，201406，201405
等到了 201408月份，那么最近三个月 201408，201407，201406
等到了201409月份，那么最近三个月 201409，201408，201407
以此类推， 范围确定不了
这个时间是变化的，一直往后增加，这个怎么确定，
例如 现在是 201407月份，那么最近三个月201407，201406，201405
等到了 201408月份，那么最近三个月 201408，201407，201406
等到了201409月份，那么最近三个月 201409，201408，201407
以此类推， 范围确定不了
#5
可以写个job来定时（比如每月执行一次）切换分区
#6
就类似删除前三个月的备份文件
#7
对于一个10亿 以上分区，witch 切换 会带来什么影响吗？ 会不会锁表等， 没有测试过。
#8
刚看了下，switch 是 转到 另外一个表中
#9
Switch会带来一定的架构锁，单分区10亿的话可能会有点性能问题，不建议单分区存放这种级别的数据
#10
说错了，应该是真个表数据量是10亿，
还是不太清楚 这个分区 该这么建立， 建立一个时间字段，这个时间字段怎么定义?
还是不太清楚 这个分区 该这么建立， 建立一个时间字段，这个时间字段怎么定义?
#11
我们业务上只是按照FID 来查询，不会按照时间查询的。
#12
a. Choosing a Table to Partition:In general, any large table has maintenance costs that exceed requirements, or that is not performing as expected due to its size, might be a candidate for table partitioning.
Index maintenance on the table is costly or time-consuming and could benefit from reindexing partitions of the table rather than the whole table at once.
Data must be aged out of the table periodically, and the delete process is currently too slow or blocks users trying to query the table.
New data is loaded periodically into the table, the load process is too slow or interferes with queries on the table, and the table data lends itself to a partition column based on ascending date or time.
i. make sure that the large table will actually benefit from partitioning; don’t partition it just because it’s big.
b. Choosing a Partition Column:Some things to note about the partition column:
The partition column must be a single column in the table (either a single column or a computed column).
If you have a combination of columns that form the best partition column, you can add a persisted computed column to the table that combines the values of the original columns and then partition on it. (For an example, see "The Rotating Window Scenario" below.) If you allow ad hoc queries against the partitioned table, those queries need to reference the computed column in their filters in order to take advantage of partition elimination.
The partition column must also have an allowable data type. (For more information about the allowable data types, see “Creating Partitioned Tables and Indexes” in SQL Server 2008 Books Online at http://msdn.microsoft.com/en-us/library/ms188730.aspx.)
In a clustered table, the partition column must be part of either the primary key or the clustered index. If the partition column is not part of the table's primary key, the partition column might allow NULL. Any data with a NULL in the partition column will reside in the leftmost partition.
The partitioning column should reflect the best way to subdivide the target table. You should look for a relatively balanced distribution of data across the resulting partitions, though it may not be possible to know that in advance.
You should also try to choose a partitioned column that will be used as a filter criterion in most of the queries run against the table. This enables partition elimination, where the query processor can eliminate inapplicable partitions from the query plan, and just access the partitions implied by the filter on the queries.
Index maintenance on the table is costly or time-consuming and could benefit from reindexing partitions of the table rather than the whole table at once.
Data must be aged out of the table periodically, and the delete process is currently too slow or blocks users trying to query the table.
New data is loaded periodically into the table, the load process is too slow or interferes with queries on the table, and the table data lends itself to a partition column based on ascending date or time.
i. make sure that the large table will actually benefit from partitioning; don’t partition it just because it’s big.
b. Choosing a Partition Column:Some things to note about the partition column:
The partition column must be a single column in the table (either a single column or a computed column).
If you have a combination of columns that form the best partition column, you can add a persisted computed column to the table that combines the values of the original columns and then partition on it. (For an example, see "The Rotating Window Scenario" below.) If you allow ad hoc queries against the partitioned table, those queries need to reference the computed column in their filters in order to take advantage of partition elimination.
The partition column must also have an allowable data type. (For more information about the allowable data types, see “Creating Partitioned Tables and Indexes” in SQL Server 2008 Books Online at http://msdn.microsoft.com/en-us/library/ms188730.aspx.)
In a clustered table, the partition column must be part of either the primary key or the clustered index. If the partition column is not part of the table's primary key, the partition column might allow NULL. Any data with a NULL in the partition column will reside in the leftmost partition.
The partitioning column should reflect the best way to subdivide the target table. You should look for a relatively balanced distribution of data across the resulting partitions, though it may not be possible to know that in advance.
You should also try to choose a partitioned column that will be used as a filter criterion in most of the queries run against the table. This enables partition elimination, where the query processor can eliminate inapplicable partitions from the query plan, and just access the partitions implied by the filter on the queries.
#13
简单来说，要看具体情况，不是一定要用时间，FID是代表什么含义？
#14
我们是处理文件的，这个FID 代表就是文件ID, 这个ID 每个月增长量在 30w 左右， 80%是处理最近3个月的数据。 其他都是历史数据。
所以现在是按照FID 来分区。
所以现在是按照FID 来分区。
#15
那用FID来分区也行。你现在是出现问题了还是担心出现问题？
#16
关于上面刚刚讨论文件组，有3个问题
1 只能有一个mdf, 但是可以有多个ndf 。
如果mdf ndf 在一个盘上，那么创建多个ndf 还有意义吗？
mdf ndf 是同时写入的，还是等mdf 写满了，在写ndf ?
2 创建表的时候可以指定filegroup ,没有指定就是在primary,
3 创建分区的时候，可以指定多个文件组 on primary, fg1,fg2,fg3 。
怎么查询数据分布在哪个fg ？
1 只能有一个mdf, 但是可以有多个ndf 。
如果mdf ndf 在一个盘上，那么创建多个ndf 还有意义吗？
mdf ndf 是同时写入的，还是等mdf 写满了，在写ndf ?
2 创建表的时候可以指定filegroup ,没有指定就是在primary,
3 创建分区的时候，可以指定多个文件组 on primary, fg1,fg2,fg3 。
怎么查询数据分布在哪个fg ？
#17
担心出现问题，
目前做法是 按照FID 进行分区，1,30w, 30w到60w, 60w到90w， 相当于1年12个分区，10年就120个分区，
这样的分区 对于历史数据 分那么多区 完成没有必要， 而且分区太多了。
目前做法是 按照FID 进行分区，1,30w, 30w到60w, 60w到90w， 相当于1年12个分区，10年就120个分区，
这样的分区 对于历史数据 分那么多区 完成没有必要， 而且分区太多了。
#18
第一个问题，如果mdf/ndf在同一个文件组，数据会按文件的空余空间按比例写入，除非某个文件设为不可增长。但是不建议把primary文件组设为不可增长或者read-only。分开多个文件某些情况下是有用的，SQL Server可以支持文件级别的备份还原。对于超大型的数据库有意义。
第二个问题：对的。
第三个问题：数据很难说分布在那个fg，可以用$partition试试，或者找找有没有相关脚本。不过根据分区函数，你应该可以算出大概区间。
#19
120个分区从技术上来说实在不多，但是管理上也的确有点头痛，所以叫你把历史数据移到一个大分区，单独放到一个文件组
#20
所以叫你把历史数据移到一个大分区，单独放到一个文件组.
但是这样要建立一个新表，相当于 现在有2个表， 一个 last ,一个his 的， 但是这样对程序来说就比较麻烦了，假如修改文件，要判断是在last 还是在his 里面， 当初就是因为这个，才选用分区表。
但是这样要建立一个新表，相当于 现在有2个表， 一个 last ,一个his 的， 但是这样对程序来说就比较麻烦了，假如修改文件，要判断是在last 还是在his 里面， 当初就是因为这个，才选用分区表。
#21
不用新建表啊，新建个空的分区就可以了
#22
我明白你的意思， 但是 问题还是 在不能确定 大分区 范围啊， 因为FID 在不停的增长，动态的。 不知道这样可以不？
现在是
1-30w 分区1
30-60w 分区2
60-90w 分区3
90-120w 分区四
。。。。
在一个特定的时间执行 分区合并，例如把 分区1 2 3 进行合并。
现在是
1-30w 分区1
30-60w 分区2
60-90w 分区3
90-120w 分区四
。。。。
在一个特定的时间执行 分区合并，例如把 分区1 2 3 进行合并。
#23
那不合并大分区也行，一个系统很少真的能不变化地用10年
#24
那不合并大分区也行，一个系统很少真的能不变化地用10年 ？？？
你的意思是 不合并的话，还是用120个分区，可是分区多了，势必会影响 插入，删除 ， 更新的速度的。
你的意思是 不合并的话，还是用120个分区，可是分区多了，势必会影响 插入，删除 ， 更新的速度的。
#25
分区另外一个好处是在并行插入，你如果带有where条件的insert、delete，有分区更加高效
#26
关于你私信的问题：“想问下， 多个不同的表 理论上是可以共用同一 分区函数和分区schema， 不知道这样做会有什么影响不呢？“
最近在看分区的白皮书，理论上是可以公用，但是微软建议专用。
另外我的私信经常没提醒，偶尔点一下看才发现有，所以别私信问了，直接在帖子引用就好
最近在看分区的白皮书，理论上是可以公用，但是微软建议专用。
另外我的私信经常没提醒，偶尔点一下看才发现有，所以别私信问了，直接在帖子引用就好
#27
最近在看分区的白皮书，理论上是可以公用，但是微软建议专用。
假如 有5个表 中都含有 FID，并且都要做分区，按照一个分区2个filegroup, 那岂不是要创建 10 个filegroup.
对于不同的分区，filegroup 可以共用吗 ？
假如 有5个表 中都含有 FID，并且都要做分区，按照一个分区2个filegroup, 那岂不是要创建 10 个filegroup.
对于不同的分区，filegroup 可以共用吗 ？
#28
如果之间的逻辑相似，并且后续改动不大，可以。如果改动很大，用同一个schema可能会引起混乱
#29
你可以共享下你的白皮书吗，我刚好在设计分区，想学习下。
#30
其实我现在想做的是， 因为 现在有 4个 特别大的表， 想建立4个filegroup , 每个表 有不同filegroup,
#32
1. 只建两个分区，一个是近三（或四个月的）个月的，一个是三个月之前的。每周（月）执行一个JOB，把数据迁走；
2. 不用分区表，使用历史表的形式，近3、4个月的数据存在 T 表中，超过 3、4个月的数据，移动到 T_his 表中。
2. 不用分区表，使用历史表的形式，近3、4个月的数据存在 T 表中，超过 3、4个月的数据，移动到 T_his 表中。
#33
1. 只建两个分区，一个是近三（或四个月的）个月的，一个是三个月之前的。每周（月）执行一个JOB，把数据迁走；
有下面2个问题
1 如果现在有4个大表，每个表都有FID字段，按照 每个分区对应一个filegroup， 那么是不是要创建8个group, fg1 fg2 fg3 fg4 fg5 fg6 fg7 fg8
tba(fg1,fg2)
tbb(fg2,fg3)
tbc(fg4,fg5)
tbd(fg6,fg7)
2 每周（月）执行一个JOB，把数据迁走；
这个数据怎么迁走？ 我现在想到就是 分区合并 和 新增加。
假如1,500w 是一个历史分区，500w 后面的是另外一个分区，这数据怎么迁走 ？
有下面2个问题
1 如果现在有4个大表，每个表都有FID字段，按照 每个分区对应一个filegroup， 那么是不是要创建8个group, fg1 fg2 fg3 fg4 fg5 fg6 fg7 fg8
tba(fg1,fg2)
tbb(fg2,fg3)
tbc(fg4,fg5)
tbd(fg6,fg7)
2 每周（月）执行一个JOB，把数据迁走；
这个数据怎么迁走？ 我现在想到就是 分区合并 和 新增加。
假如1,500w 是一个历史分区，500w 后面的是另外一个分区，这数据怎么迁走 ？
#1
几十万一个分区不多，2008R2都能支持到15000个分区了。另外最近3个月才频繁的话，前面三个月可以通过分区switch，移到一个大的只读文件组上的分区中。如何分区要视乎查询所用，你所说的“xx月”，应该优先考虑以时间来做分区列
#2
还有 个问题， 如果 分区都放在一个primary 文件组， 和 放在多个 文件组 里面有什么区别?
#3
1、管理上不方便。说白了就是牵一发动全身。
2、多个文件组如果放在不同的物理磁盘，并且分区对齐、磁盘配置合理的话，能够加大并行读取
2、多个文件组如果放在不同的物理磁盘，并且分区对齐、磁盘配置合理的话，能够加大并行读取
#4
你所说的“xx月”，应该优先考虑以时间来做分区列
这个时间是变化的，一直往后增加，这个怎么确定，
例如 现在是 201407月份，那么最近三个月201407，201406，201405
等到了 201408月份，那么最近三个月 201408，201407，201406
等到了201409月份，那么最近三个月 201409，201408，201407
以此类推， 范围确定不了
这个时间是变化的，一直往后增加，这个怎么确定，
例如 现在是 201407月份，那么最近三个月201407，201406，201405
等到了 201408月份，那么最近三个月 201408，201407，201406
等到了201409月份，那么最近三个月 201409，201408，201407
以此类推， 范围确定不了
#5
可以写个job来定时（比如每月执行一次）切换分区
#6
就类似删除前三个月的备份文件
#7
对于一个10亿 以上分区，witch 切换 会带来什么影响吗？ 会不会锁表等， 没有测试过。
#8
刚看了下，switch 是 转到 另外一个表中
#9
Switch会带来一定的架构锁，单分区10亿的话可能会有点性能问题，不建议单分区存放这种级别的数据
#10
说错了，应该是真个表数据量是10亿，
还是不太清楚 这个分区 该这么建立， 建立一个时间字段，这个时间字段怎么定义?
还是不太清楚 这个分区 该这么建立， 建立一个时间字段，这个时间字段怎么定义?
#11
我们业务上只是按照FID 来查询，不会按照时间查询的。
#12
a. Choosing a Table to Partition:In general, any large table has maintenance costs that exceed requirements, or that is not performing as expected due to its size, might be a candidate for table partitioning.
Index maintenance on the table is costly or time-consuming and could benefit from reindexing partitions of the table rather than the whole table at once.
Data must be aged out of the table periodically, and the delete process is currently too slow or blocks users trying to query the table.
New data is loaded periodically into the table, the load process is too slow or interferes with queries on the table, and the table data lends itself to a partition column based on ascending date or time.
i. make sure that the large table will actually benefit from partitioning; don’t partition it just because it’s big.
b. Choosing a Partition Column:Some things to note about the partition column:
The partition column must be a single column in the table (either a single column or a computed column).
If you have a combination of columns that form the best partition column, you can add a persisted computed column to the table that combines the values of the original columns and then partition on it. (For an example, see "The Rotating Window Scenario" below.) If you allow ad hoc queries against the partitioned table, those queries need to reference the computed column in their filters in order to take advantage of partition elimination.
The partition column must also have an allowable data type. (For more information about the allowable data types, see “Creating Partitioned Tables and Indexes” in SQL Server 2008 Books Online at http://msdn.microsoft.com/en-us/library/ms188730.aspx.)
In a clustered table, the partition column must be part of either the primary key or the clustered index. If the partition column is not part of the table's primary key, the partition column might allow NULL. Any data with a NULL in the partition column will reside in the leftmost partition.
The partitioning column should reflect the best way to subdivide the target table. You should look for a relatively balanced distribution of data across the resulting partitions, though it may not be possible to know that in advance.
You should also try to choose a partitioned column that will be used as a filter criterion in most of the queries run against the table. This enables partition elimination, where the query processor can eliminate inapplicable partitions from the query plan, and just access the partitions implied by the filter on the queries.
Index maintenance on the table is costly or time-consuming and could benefit from reindexing partitions of the table rather than the whole table at once.
Data must be aged out of the table periodically, and the delete process is currently too slow or blocks users trying to query the table.
New data is loaded periodically into the table, the load process is too slow or interferes with queries on the table, and the table data lends itself to a partition column based on ascending date or time.
i. make sure that the large table will actually benefit from partitioning; don’t partition it just because it’s big.
b. Choosing a Partition Column:Some things to note about the partition column:
The partition column must be a single column in the table (either a single column or a computed column).
If you have a combination of columns that form the best partition column, you can add a persisted computed column to the table that combines the values of the original columns and then partition on it. (For an example, see "The Rotating Window Scenario" below.) If you allow ad hoc queries against the partitioned table, those queries need to reference the computed column in their filters in order to take advantage of partition elimination.
The partition column must also have an allowable data type. (For more information about the allowable data types, see “Creating Partitioned Tables and Indexes” in SQL Server 2008 Books Online at http://msdn.microsoft.com/en-us/library/ms188730.aspx.)
In a clustered table, the partition column must be part of either the primary key or the clustered index. If the partition column is not part of the table's primary key, the partition column might allow NULL. Any data with a NULL in the partition column will reside in the leftmost partition.
The partitioning column should reflect the best way to subdivide the target table. You should look for a relatively balanced distribution of data across the resulting partitions, though it may not be possible to know that in advance.
You should also try to choose a partitioned column that will be used as a filter criterion in most of the queries run against the table. This enables partition elimination, where the query processor can eliminate inapplicable partitions from the query plan, and just access the partitions implied by the filter on the queries.
#13
简单来说，要看具体情况，不是一定要用时间，FID是代表什么含义？
#14
我们是处理文件的，这个FID 代表就是文件ID, 这个ID 每个月增长量在 30w 左右， 80%是处理最近3个月的数据。 其他都是历史数据。
所以现在是按照FID 来分区。
所以现在是按照FID 来分区。
#15
那用FID来分区也行。你现在是出现问题了还是担心出现问题？
#16
关于上面刚刚讨论文件组，有3个问题
1 只能有一个mdf, 但是可以有多个ndf 。
如果mdf ndf 在一个盘上，那么创建多个ndf 还有意义吗？
mdf ndf 是同时写入的，还是等mdf 写满了，在写ndf ?
2 创建表的时候可以指定filegroup ,没有指定就是在primary,
3 创建分区的时候，可以指定多个文件组 on primary, fg1,fg2,fg3 。
怎么查询数据分布在哪个fg ？
1 只能有一个mdf, 但是可以有多个ndf 。
如果mdf ndf 在一个盘上，那么创建多个ndf 还有意义吗？
mdf ndf 是同时写入的，还是等mdf 写满了，在写ndf ?
2 创建表的时候可以指定filegroup ,没有指定就是在primary,
3 创建分区的时候，可以指定多个文件组 on primary, fg1,fg2,fg3 。
怎么查询数据分布在哪个fg ？
#17
担心出现问题，
目前做法是 按照FID 进行分区，1,30w, 30w到60w, 60w到90w， 相当于1年12个分区，10年就120个分区，
这样的分区 对于历史数据 分那么多区 完成没有必要， 而且分区太多了。
目前做法是 按照FID 进行分区，1,30w, 30w到60w, 60w到90w， 相当于1年12个分区，10年就120个分区，
这样的分区 对于历史数据 分那么多区 完成没有必要， 而且分区太多了。
#18
第一个问题，如果mdf/ndf在同一个文件组，数据会按文件的空余空间按比例写入，除非某个文件设为不可增长。但是不建议把primary文件组设为不可增长或者read-only。分开多个文件某些情况下是有用的，SQL Server可以支持文件级别的备份还原。对于超大型的数据库有意义。
第二个问题：对的。
第三个问题：数据很难说分布在那个fg，可以用$partition试试，或者找找有没有相关脚本。不过根据分区函数，你应该可以算出大概区间。
#19
120个分区从技术上来说实在不多，但是管理上也的确有点头痛，所以叫你把历史数据移到一个大分区，单独放到一个文件组
#20
所以叫你把历史数据移到一个大分区，单独放到一个文件组.
但是这样要建立一个新表，相当于 现在有2个表， 一个 last ,一个his 的， 但是这样对程序来说就比较麻烦了，假如修改文件，要判断是在last 还是在his 里面， 当初就是因为这个，才选用分区表。
但是这样要建立一个新表，相当于 现在有2个表， 一个 last ,一个his 的， 但是这样对程序来说就比较麻烦了，假如修改文件，要判断是在last 还是在his 里面， 当初就是因为这个，才选用分区表。
#21
不用新建表啊，新建个空的分区就可以了
#22
我明白你的意思， 但是 问题还是 在不能确定 大分区 范围啊， 因为FID 在不停的增长，动态的。 不知道这样可以不？
现在是
1-30w 分区1
30-60w 分区2
60-90w 分区3
90-120w 分区四
。。。。
在一个特定的时间执行 分区合并，例如把 分区1 2 3 进行合并。
现在是
1-30w 分区1
30-60w 分区2
60-90w 分区3
90-120w 分区四
。。。。
在一个特定的时间执行 分区合并，例如把 分区1 2 3 进行合并。
#23
那不合并大分区也行，一个系统很少真的能不变化地用10年
#24
那不合并大分区也行，一个系统很少真的能不变化地用10年 ？？？
你的意思是 不合并的话，还是用120个分区，可是分区多了，势必会影响 插入，删除 ， 更新的速度的。
你的意思是 不合并的话，还是用120个分区，可是分区多了，势必会影响 插入，删除 ， 更新的速度的。
#25
分区另外一个好处是在并行插入，你如果带有where条件的insert、delete，有分区更加高效
#26
关于你私信的问题：“想问下， 多个不同的表 理论上是可以共用同一 分区函数和分区schema， 不知道这样做会有什么影响不呢？“
最近在看分区的白皮书，理论上是可以公用，但是微软建议专用。
另外我的私信经常没提醒，偶尔点一下看才发现有，所以别私信问了，直接在帖子引用就好
最近在看分区的白皮书，理论上是可以公用，但是微软建议专用。
另外我的私信经常没提醒，偶尔点一下看才发现有，所以别私信问了，直接在帖子引用就好
#27
最近在看分区的白皮书，理论上是可以公用，但是微软建议专用。
假如 有5个表 中都含有 FID，并且都要做分区，按照一个分区2个filegroup, 那岂不是要创建 10 个filegroup.
对于不同的分区，filegroup 可以共用吗 ？
假如 有5个表 中都含有 FID，并且都要做分区，按照一个分区2个filegroup, 那岂不是要创建 10 个filegroup.
对于不同的分区，filegroup 可以共用吗 ？
#28
如果之间的逻辑相似，并且后续改动不大，可以。如果改动很大，用同一个schema可能会引起混乱
#29
你可以共享下你的白皮书吗，我刚好在设计分区，想学习下。
#30
其实我现在想做的是， 因为 现在有 4个 特别大的表， 想建立4个filegroup , 每个表 有不同filegroup,
#31
#32
1. 只建两个分区，一个是近三（或四个月的）个月的，一个是三个月之前的。每周（月）执行一个JOB，把数据迁走；
2. 不用分区表，使用历史表的形式，近3、4个月的数据存在 T 表中，超过 3、4个月的数据，移动到 T_his 表中。
2. 不用分区表，使用历史表的形式，近3、4个月的数据存在 T 表中，超过 3、4个月的数据，移动到 T_his 表中。
#33
1. 只建两个分区，一个是近三（或四个月的）个月的，一个是三个月之前的。每周（月）执行一个JOB，把数据迁走；
有下面2个问题
1 如果现在有4个大表，每个表都有FID字段，按照 每个分区对应一个filegroup， 那么是不是要创建8个group, fg1 fg2 fg3 fg4 fg5 fg6 fg7 fg8
tba(fg1,fg2)
tbb(fg2,fg3)
tbc(fg4,fg5)
tbd(fg6,fg7)
2 每周（月）执行一个JOB，把数据迁走；
这个数据怎么迁走？ 我现在想到就是 分区合并 和 新增加。
假如1,500w 是一个历史分区，500w 后面的是另外一个分区，这数据怎么迁走 ？
有下面2个问题
1 如果现在有4个大表，每个表都有FID字段，按照 每个分区对应一个filegroup， 那么是不是要创建8个group, fg1 fg2 fg3 fg4 fg5 fg6 fg7 fg8
tba(fg1,fg2)
tbb(fg2,fg3)
tbc(fg4,fg5)
tbd(fg6,fg7)
2 每周（月）执行一个JOB，把数据迁走；
这个数据怎么迁走？ 我现在想到就是 分区合并 和 新增加。
假如1,500w 是一个历史分区，500w 后面的是另外一个分区，这数据怎么迁走 ？