【产品名称】observer
【产品版本】v3.1.2
【问题描述】在同一客户端，drop 表之后重新建表（表结构不变)，plan cache 命中率为0。
多次重复上诉操作后，有几率出现为100%的情况，也出现为0和100 中间值的情况。
按机器过滤查看命中率，发现机器之间的命中率确实不一致。
猜测：删表之后，会出发plan cache的淘汰机制，observer各机器之间会各自重建plan cache。重建表之后，主分区所在的机器可能发生改变。
不知道猜测对不对。另外为了解决重建表后的SQL执行性能问题，目前还没有想到好的办法。
重新建表后，应该属于schema变更了，需要对计划缓存进行刷新。每个节点的cache都是自己维护的，所以可能存在不一致性的情况
查询优化过程依赖数据统计信息的准确性，OceanBase 数据库的优化器默认会在数据合并过程中收集一些统计信息，当用对数据进行了大量修改时，可能会导致统计信息落后于真实数据的特征，用户可以通过发起每日合并，主动更新统计信息。
除了优化器收集的统计信息以外，优化器还会根据查询条件对存储层进行采样，用以后续的优化选择。OceanBase 数据库目前仅支持对本地存储进行采样，对于数据分区在远程节点上的情况，只能使用默认收集的统计信息进行代价估计，可能会引入代价偏差。