论坛到底有没有Oracle数据库专家?

[深圳gg]

今天在csdn首页上看到一篇文章：数据库性能优化之SQL语句优化 http://blog.csdn.net/u011225629/article/details/50492403
很多内容都是胡说八道，列几点出来


文章在哪里抄的，很多都是错的，我先把错误的离谱的随便列出来，如果你反驳，我就给出例子。
1.在业务密集的SQL当中尽量不采用IN操作符，用EXISTS 方案代替。--在oracle 10g之后，两个的执行计划其实就一样了，就说两个的性能都一样了。
2.NOT IN和NOT EXISTS两个含义都不一样，如果not in 后面的子查询中有Null值，是没有数据的。
3.is not null的语句优化器是不允许使用索引的SQL> select count(1) from test where object_id is not null;
执行计划
----------------------------------------------------------
Plan hash value: 3841213438
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5 | 651 (3)| 00:00:08 |
| 1 | SORT AGGREGATE | | 1 | 5 | | |
|* 2 | INDEX FAST FULL SCAN| IND_T_OBJECT_ID | 1054K| 5151K| 651 (3)| 00:00:08 |
-----------------------------------------------------------------------------------------
4.WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响。查询表顺序的影响。
WHERE子句中的连接顺序
20年前RBO时代是这样，过时了。
5.尽量多使用COMMIT，commit越频繁，性能越低。
6.用IN来替换OR，经过查询转换后，都是一样的了。

[kingkingzhu]

优化没有绝对吧 不同的环境不同的数据量不同的版本 都会有些差异 最适合自己的才是最好的

[深圳gg]

晕倒，我说他写的是错的

[zbdzjx]

那篇文章应该是转载的吧，印象中，很多年前就看过了。

[惜分飞]

5.尽量多使用COMMIT，commit越频繁，性能越低。 这个相对的，具体看场景，有些plsql，如果你不及时提交，可能导致tx锁延迟非常大，后果更加严重

[小灰狼W]

不是我的博客，松了口气，哈哈哈哈 其实网络上的很多优化规则都是不适用的，大部分是因为版本的更新以后，旧规则在新版本中并不适用。所以技术的东西，写的人要负责任以外，看的人也要有自己的思想 1. in和exists之争，在10g以后优化了很多，以至于很多时候可以近乎相等。优化器的判断更智能，不代表完全不会受写法的影响。关于这点，我持保留态度。当然exists一定比in优化是很不靠谱的说法 2. 的确是这样。但优化的出发点是性能，业务和数据的问题暂且撇开。实际使用的时候确实要注意避开这个雷 3. 文中的不适用索引，指的是通过索引来快速定位。而楼主这里的INDEX FAST FULL SCAN是因为count(1)所需要的记录在该索引中全都有，因此对索引进行全扫描比对表进行全扫描块数更少。也就是说，连接中的博客的观点，应该指的是index range scan 4. cbo以后就不再适用。还在说条件顺序的，引用的是早期的材料 5. commit频率主要在于业务。性能上来说，批量比一条一条执行快，这个角度上，不应该太频繁commit。但是量太大的话，会使得占用资源不释放反而影响效率，因此也不宜过长 6. 在我理解中，in和or是一样的，就像between 等价于>= and <=

[lhdz_bj]

这年头，别太拿专家当回事儿，真真假假，以假乱真是常态，还是相信自己，相信自己的判断为好。 1、现在高版本的商用库，包括开源库都是CBO的，语法影响没那么绝对，但特殊情况，写法还是有影响的。 2、is not null条件的语句不能走索引，这个是有很多前提条件的。 3、commit提交频度的问题，看具体业务，高并发系统是要尽快提交的，低并发大批量加载数据业务就不必了。

[xu176032]

尽信书不如无书，书上写的东西都可能是错的，为啥一定要强制要求博客上写就是对的呢，博客上写的东西可能只是大家自己的心得体会吧，我觉得是这样，可能仅仅是适用自己的系统，自己的项目，没有必要这么较真，拿别人的东西过来用的时候自己验证一下就好了，合适就用，不合适就不用，没啥好争议的，也争论不出来谁对谁错。

[深圳gg]

你写blog对不对，这个跟我没关系，但发布在csdn首页上就有问题，这么多人看，你必须是对的，明白吗？

[jdsnhan]

事无绝对，具体问题具体分析。

[深圳gg]

你说一个具体的例子

[深圳gg]

引用 5 楼 xifenfei 的回复:

5.尽量多使用COMMIT，commit越频繁，性能越低。 这个相对的，具体看场景，有些plsql，如果你不及时提交，可能导致tx锁延迟非常大，后果更加严重

1. 在plsql里面提不提交也是具体的业务来说，如果为了事务的完整性不能提交，那就不能提交。 2. Insert数据，是不是越频繁commit，效率越低。 我想说的是，在首页的博客上，不要发布一些似是而非的东西，误导大家。

[深圳gg]

不要在回一些事无绝对这样没用的话。我想说的是，在csdn首页上发布这些事实而非的东西，误导初学者，这样对吗？ 就像说在oracle中书写SQL，小表写在前面，大表写在后面，过滤数据最多的条件放在最后面，这种说法你要抬杠，说对啊，我现在用11g，写SQL都是使用RBO，就是这样的，我就TM的无语了。

[lhdz_bj]

是自己的就好，就怕东拼西凑，这种东西负能量确实很大的，不是每个人都有鉴别力，真有鉴别力的就不去网上找这些帖子看了，起码不会信，如果初学者看到这种，那还真麻烦，很多初学者理论体系里充斥着这种东西，每次看到他们振振有词的宣讲或讲解这些东西，觉得好无奈。

[深圳gg]

楼上的兄弟，深有同感啊，大部分初学者都是这样，很无语，也很无力

[xiaobluesky]

1.在业务密集的SQL当中尽量不采用IN操作符，用EXISTS 方案代替。 不发表意见，其实差不多。。 2.NOT IN和NOT EXISTS两个含义都不一样，如果not in 后面的子查询中有Null值，是没有数据的。 not in关联的问题在于，会导致内表查询不能走索引。。有特殊情况，大部分情况下适用，别钻牛角尖 3.is not null的语句优化器是不允许使用索引 索引不记录空值而已，关键的是你用is null看下，还走索引嘛？？？ 4.WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响。查询表顺序的影响。 WHERE子句中的连接顺序 20年前RBO时代是这样，过时了。 最烦这点，过时！！也许不适用现在的系统，但是，这样写绝对没有坏处，据说所知10g至少得系统不是没有，rbo并不是没人用！！！ 5.尽量多使用COMMIT，commit越频繁，性能越低。 常识吧？1条和1000条提交一次。。是质的差别。。 6.用IN来替换OR，经过查询转换后，都是一样的了。 or基本一定会走全表扫描。如果可以转换，当然要转。。 这些条件在大部分情况下，都是适用的，都是以前好的经验，虽然有几条过时，但不代表有问题。。最烦自己没总结，成天喷别人的。。

[xiaobluesky]

这个文档我应该4年前就看过类似的，推算作者写的时候应该至少10年以前，就算拿到现在来看，也没有什么错误的地方，只是某些不适用了而已。。但绝没有坏处

[深圳gg]

你说的都是错的，可以看出你根本没做过优化，刚毕业吧

[深圳gg]

你没有看到blog是2016年1月份发的吗？