1.索引缘何频频失效

分区表的不当操作导致分区索引失效，

STATUS是N/A的表示是局部索引

观察全局索引和局部索引的状态

分区truncate操作，看看索引是否会失效，参见脚本4-46：

做分区truncate后全局索引失效，局部索引未失效

对索引进行了重建工作，以让索引生效：

对失效的全局索引进行重建

分区表的分区操作，对局部索引一般都没有影响，但是对全局索引影响比较大。

Oracle在提供这些分区操作时提供了一个很有用的参数update globalindexes，可以有效地避免全局索引失效。这个参数的本质是，在分区操作做完后，暗暗执行索引重建的工作。

update global indexes关键字可避免全局索引失效

其他分区操作，如分区转移、切割、合并、增删等，和这个分区 truncate是类似的，都允许增加update global indexes关键字，从而避免全局索引失效。

2.有索引效率反而更低

设计不当产生的性能问题。

对其中的id列建一个局部索引，然后对norm_tab表的id列也建一个索引。

针对类似select * from norm_tabwhere id=888；分区表查询是否比普通表更快：

应用分区表的局部索引产生的逻辑读很大

普通表的查询情况:

应用普通表的普通索引产生的逻辑读很小

普通表查询的性能好，分区表的逻辑读是240，而普通表才4。分区表的Cost是15，而普通表的Cost为2。索引的高度一般比较低。

无法应用分区条件

在设计分区时，往往没有预先规划好如何应用分区，这是不对的。操作的是分区表，却不用分区条件，从而无法做到分区消除，这就浪费了分区表的宝贵特性，应该避免出现类似情况。

分区表设计要考虑在语句中有效用到分区条件，有无分区条件差别巨大

性能提升了许多，逻辑读从原来的240瞬间降到3，其实原因在于之前遍历了所有的分区，现在只访问指定的分区。