有日子没有来更新博客了，今天上来一看，发现收视率又获得了2个点的提高，感谢兔子弟弟给哥哥带来收视率的提升。
今天股市很牛，大盘已经逼近了3000点，朋友小样的股票又升了，哈哈，恭喜她，某支股票的收益率竟然是900%多，嘿嘿，多宣扬一下可以上小报了。可惜，今天我的股票表现很是不好，居然还跌了一分钱，真的是很意外。看来，持币过年的愿望不能实现了，不过还好，反正也没有多少钱在股市里，也许年后有惊喜呢，哈哈，既然改变不了现实，那就只有改变自己的心情珞。阿q一下还挺开心。不过，今天还是挺高兴的，因为下午就可以回家了，看望久别的父母家人，与老同学们聚聚会，吃吃家乡的美味，心情真不错。
回家了，朋友们，年后见！
2007年2月6日星期二
Oracle - 表间顺序
在对Oracle查询进行优化的时候，大家的重点一般落在索引的建立使用、提示的使用等方面，往往会忽略表间顺序的问题，在进行简单的多表查询的时候，按照正常的业务逻辑得出的结果，有可能会造成效率的极大降低。
例如：人物表Person有记录10万，状态表(State)有记录100万。
现要找在10天内发生变化的人物信息，只要将人物表的pid与状态表的id相关联，并且定位时间条件即可，按照正常思维逻辑的很容易得出如下写法：
select p.* from Person p, State s where p.pid=s.id and s.updtime>sysdate-10
按照这种写法，当然也能得出来结果，可是经过查看执行计划，发现查找过程是以State为基础表执行的，实际上我们完全可以用Person表做为基础表进行查询，这样可以极大地简化计算量，所要做的就是将表的前后顺序调换一下，将数据量较小的表放在后面作为基础表，如下：
select p.* from State s，Person p where p.pid=s.id and s.updtime>sysdate-10
经过以上调整，计算量简化了，效率也提高了。当然如果只是2个表间的关联查询，性能上的提升在目前超高的计算机计算速度下，不是那么明显。可是，一些复杂的语句里，几处这样微小的调整可能带来整体效率几十倍甚至上百倍的提升。
当然Oracle中关于基础表的选择是一个非常复杂的过程，不是简单的表间顺序就能决定的。Oracle的优化网上个有很多的资料可以参考，并不是当前关注的重点。但是一个不好的习惯往往在不经意间，就会造成效率的低下，并且不易察觉。本文想要提醒的，同样也是非常容易被忽略的一个问题就是：在进行检索查询的时候，一定要留心表间顺序,基础表的正确选择有时候会带来效率的提升，反之。。。。。
例如：人物表Person有记录10万，状态表(State)有记录100万。
现要找在10天内发生变化的人物信息，只要将人物表的pid与状态表的id相关联，并且定位时间条件即可，按照正常思维逻辑的很容易得出如下写法：
select p.* from Person p, State s where p.pid=s.id and s.updtime>sysdate-10
按照这种写法，当然也能得出来结果，可是经过查看执行计划，发现查找过程是以State为基础表执行的，实际上我们完全可以用Person表做为基础表进行查询，这样可以极大地简化计算量，所要做的就是将表的前后顺序调换一下，将数据量较小的表放在后面作为基础表，如下：
select p.* from State s，Person p where p.pid=s.id and s.updtime>sysdate-10
经过以上调整，计算量简化了，效率也提高了。当然如果只是2个表间的关联查询，性能上的提升在目前超高的计算机计算速度下，不是那么明显。可是，一些复杂的语句里，几处这样微小的调整可能带来整体效率几十倍甚至上百倍的提升。
当然Oracle中关于基础表的选择是一个非常复杂的过程，不是简单的表间顺序就能决定的。Oracle的优化网上个有很多的资料可以参考，并不是当前关注的重点。但是一个不好的习惯往往在不经意间，就会造成效率的低下，并且不易察觉。本文想要提醒的，同样也是非常容易被忽略的一个问题就是：在进行检索查询的时候，一定要留心表间顺序,基础表的正确选择有时候会带来效率的提升，反之。。。。。
订阅：
博文 (Atom)
