难道是rebuild index的一个bug？

今天在分析一条语句的时候，一个表也就10来行记录，segment的大小也就5M，通过查看其执行计划，发现是走索引的，但是却有5000多的cr。奇怪，之前表刚刚做过move tablespace and rebuild index，按理说rebuild index之后，10来行记录的cr不会有5000多呀！

测试了一下加个full的hints，发现cr才20多。难道是gather table stats的信息有问题？再次收集一次，还是和原来一样，用analyze收集一次，也是一样，blevel是0，leaf block也很少。这么少的block走索引产生5000多的cr，真的有问题呀。

用treedump把index dump出来看看：alter session set events ‘immediate trace name treedump,level object_id’;检查发现原来实际的leaf block要比之前收集到的统计信息多很多，而且也有2个branch！！

看来原因就在这里了，index在rebuild之后，可能状态已经恢复了valid，但是block还没有重组，虽然分析之后的统计信息能看到，但是这个信息是不准确的，此时一定要通过treedump来观察实际的leaf block和blevel。难道，这是一个rebuild index的bug么？

最后，通过drop index and create index解决该问题。看执行计划是走索引，也只有20多的cr了。