再请教yupeigu分区的一些知识

[ufo20020427]

首先谢谢在http://bbs.csdn.net/topics/390644402的解答。
但还有两个疑问，想请教下。

1.对于temp_UserBill表，我多次测试，如果保留BusinessDate（分区字段）的聚集索引，发现插入的速度，比删除这个索引还要快。保留这个索引，基本只要1分钟左右，反之，要2分钟左右。


2.关于switch partitio方案，由于目标分区表除了BusinessDate字段，还有其他非聚焦索引（例如F1字段）。现在把临时导入的表，直接swithch到目标分区表中。

这样的情况下，是不是F1字段的索引，只在所属分区中有效（有序）,而在整个表所有分区中是无效（无序）,要不如果所有区都重排的话，应该无法那么快是吧？

谢谢！

[LongRui888]

哦 1、你的意思是，如果有这个聚集索引，那么插入的时候，速度非常快，如果是没这个聚集索引，那么同样的插入，就慢是吧？

[LongRui888]

2、如果你建立的就是个普通的非聚集索引，那么确实会导致这个索引失效， 相当于现在，你有5个分区，然后，建立了一个非聚集索引，于是，这个索引，把5个分区的数据全部进行排序，在硬盘上建了这个索引，索引里存储的其实就是，比如： aaa rowid aaa rowid bbb rowid ccc rowid 这里的rowid其实就是用来定位，这个aaa值，是在哪儿，比如：那个文件、那个page、那个行。 这样当我们把另一个表的第5个分区，切换成分区表的第5个分区时，数据确实是切换了，但是这个新插入的数据中的F1列的值，并没有反应到 这个非聚集索引中，那么会导致这个索引无效。 那么如何来解决这个问题呢，这个和第1个问题相关，就是为什么有了聚集索引，你可以这样建立你的非聚集索引：

create index idx_temp_UserBill_f1 on temp_UserBill(f1)
on wcLeftRangeScheme(BusinessDate)

注意这个语句所创建的索引是分区索引，不是普通的索引，也就是说，这个f1索引也按照分区字段，把整个索引分成了，假设是有5个分区，那么这个索引就被分成了5分，这样设置之后，你再进行分区切换时，这个非聚集索引就不会失效了。 但是这个非聚集索引，有个问题，就是你查询的时候，最好在where 条件中，指定2个查询条件，一个是BusinessDate字段的条件，一个是F1字段的条件，这样的话，sql server首先根据BusinessDate字段，定位某个分区，然后只在这个分区中查找F1，这样速度要快一点。 否则，如果只提供F1字段，那么你有5个分区，他就会去5个分区中，分别查找F1的值，然后来个union all，也就是等价于这样： select * from 表 where 分区1 and f1 = 'xx' union all select * from 表 where 分区2 and f1 = 'xx' union all ... 下面是普通的索引,也就是只存在一份，一个整体，而不是分成5分：

create index idx_temp_UserBill_f1 on temp_UserBill(f1)

[LongRui888]

关于第1个问题，之所以有了聚集索引速度反而快，应该是和 分区表字段BusinessDate 有关。 而且可能比较特别的是，由于每个分区中，BusinessDate 字段的值都是一样的，比如都是'201311',而且正好是分区字段，所以效率比较高吧。

[ufo20020427]

太谢谢你了！ 要是MSDN的例子由你来写，我就不会看得一头雾水了！

[LongRui888]

引用 4 楼 ufo20020427 的回复:

太谢谢你了！ 要是MSDN的例子由你来写，我就不会看得一头雾水了！

确实啊，我之前也查了不少MSDN，基本上看了和没看差不多，看完了还是不明白，呵呵。