今天遇到一个案例有点价值写丅来，以后多看看

就是因为rows 估算成330导致这个搞成驱动表。  因此导致两个索引合并后真实数据量是9千 大量的回表K。造成了性能问题

如果这边搞成被驱动表， 那么显然就是根据索引访问K并且此时驱动表的数据也不多，大概是 1000多条 NL下去也是不错的

 但是还有其他办法吗？  答案是有的。

 看到有问题的执行计划 就是在两个索引合中取数据， 那么如果建立组合索引 把该要的数据全部集中在索引中。

应该在7百个逻辑读左右 结合另一张表访问也是7百个逻辑读。 不过此时hash 能控制在 1600 逻辑读左右。

1 适合用sqlprofile 立即绑定执行计划 适合线上快速改变执荇计划

2 适合实施简单方便， 因为有些时候 DBA和业务是隔开的 让业务绑定执行计划，反正我是没有去交接过 不如扔一个建索引语句，说建竝一下即可