针对百万级数据库优化方案文章的疑问

https://blog.csdn.net/wuhuagu_wuhuaguo/article/details/72875054#commentsedit

上面所谓的宝典,一定都是对的吗?

记住:oracle的优化是对CBO的深刻理解! 不经测试的结论不要相信

下面按顺序回答上面对于的说明:(针对oracle)

1.建不建索引,要跟据实际情况来定,而不是有order by就加索引

2.用了null,不能用组合索引吗?

3.<> 是谁说一定走全表扫?

4.如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描;

这个在12c 会自已转换为union all

5. in 和 not in 也要慎用，否则会导致全表扫描,

in跟导不导致全表扫没有关系,反而使用in的子查询会让CBO有更多的路径选择;从而选择最优的执行计划;

所以我是推荐in的

6.‘%abc%’确实会走全表扫,除了全文索引,还可以减少列体积

9.避免在where子句中对字段进行函数操作,这句话是对的,但是确定一定全表扫,函数索引不行吗?

11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用;

索引中的第一个字段没有使用难道不能走 index skip scan?

12,select col1,col2 into #t from t where 1=0是为了快速的复制表结构,

说耗资源的,create table就不耗资源吗?

14.性能差不差跟你的执行计划以及表数据量有关; 这里说的分页是什么意思?

15select count(*) from table 谁说一定走全表扫的,不能走ffs?,其性能跟count(1)一样!

19.varchar是效率换空间,char是空间换效率

20任何地方都不要使用 select * from t ,这个要看实际情况,我一个游标要返回所有记录不行吗?

23如果一次性插入数据量很大，那么可以使用 select into 代替 create table;

记住, create table as的效率最高;而且产生的log很少,select into效率很低(不推荐使用),如果你担心log;

create table nologging as..

24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。这种显然是建了一个普通表,当做临时表处理;肯定效率不好;

推荐,事务临时表/回话临时表;无需适度

25;尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。

谁说游标效率差的, 大数据的批量更新不使用游标?

游标本身是一个载体,性能的关键点在于sql;

30;对 大数据量的 DELETE 或INSERT ,推荐使用批量提交+append_value或者分片rowid