再请教yupeigu分区的一些知识
首先谢谢在http://bbs.csdn.net/topics/390644402的解答。
但还有两个疑问，想请教下。

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


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

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

谢谢！





------解决方案--------------------

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)