在最外层使用select * from 会降低性能吗

Question

直接select * 会导致解析table的定义字典，
但例如： select * from (select empno,deptno from emp) 
在这种情况下使用select * 还会有解析的问题吗，会降低性能吗？

Answer 1

*，不是决定性能的主要问题。
如果你的sql语句性能优问题，那么你应该从你的子查询的优化开始·

Answer 2

SELECT COUNT(*) FROM srcs.cm_user;--2494584记录select * from srcs.cm_user的解析
SELECT STATEMENT, GOAL = ALL_ROWS 13272 2485876 415141292
TABLE ACCESS FULL SRCS CM_USER                 13272 2485876 415141292select * from (select * from srcs.cm_user)的解析
SELECT STATEMENT, GOAL = ALL_ROWS 13272 2485876 415141292
 TABLE ACCESS FULL SRCS CM_USER                 13272 2485876 415141292从上面的代码的解析来看,没有影响吧,有人有其它的测试吗?

Answer 3

select * 多了层sql的递归调用 去解析数据字典表 获得各个字段
因此我觉得是很有限的 
希望和大家讨论下

Answer 4

当然如果直接些 select 字段名 那么是比 select * 好

Answer 5

就你这个情况，那么只有一点点.................!
最终oracle，会解析成为另外一个sql.

Answer 6

首先基于CBO的系统执行时只会选择执行成本最低的计划去执行(8i之前或优化器指定使用基于RULE的除外.).那也就是说,同一个SQL,如果执行计划成本相同, 性能就不会有影响. 纵向比较: 
select * from (select * from (select * from (select * from (select * from (select * from table_name)))));
就上面这一句来说,你在执行的时候因为只有一个表(假设只是一个表,视图也一样,), 这样同样的SQL在执行的时候他的计划如果数据库参数没有改变的话,和select * from table_name是相同的. 这两个SQL的不同点就是:前者比后者多了几十个字符,而这几十个字符是需要从网络上传递到数据库的. 网络多处理这么几个字符的时间可以忽略不计. 这就是说这两个SQL的性能几乎相等. 横向比较:
就上面嵌套的那个SQL来说, 如果table_name是一个很复杂的视图, 如果单独执行该视图要解析十分钟(这是假设,也就是说从执行开始,到该SQL返回记录这段时间.), 如果时间很长,说明优化器在解析的时候化了太多的时间. 这就不是一个好的SQL了. 姑且先不论. Oracle解析SQL之后, 会将SQL解析结果放到LRU列表中,放在最前的是最热的,放在右面的将会慢慢地被放在前面的挤出队列. 而下次再执行的时候,如果发现已经解析过的SQL没有变化,则不再解析,这样就会省很多时间. 也就是说,如果你刚成功执行了该复杂的SQL.十分钟, 在短暂的时间之后再执行,则会很快,有可能就几秒就会返回数据. 而如果时间很短,则我们就感觉不到性能的变化了(比如一SQL用了0.1秒就完成,现在性能提高了10倍0.01秒就完成了,我们就感觉不到了).

Answer 7

谢谢大家的讨论 其实我主要想问的是
select * from (select empno,deptno from emp) 
相比
select empno,deptno  from (select empno,deptno from emp) 
有没有性能下降，如果有，怎么能分析出来，执行计划似乎看不出来吧

Answer 8

参考书中关于recursive calls的地方看看－主要消耗的是CPU 。

Answer 9

select * 这样的东西一般来讲跟执行计划无关，也就是说从索引定位到数据的效率是一样的（如果只查询索引列另计）。
但是select *会产生解析数据字典、并且夸张点说，如果你的这个表有200个字段，其中又有一些是CLOB什么的，那么这样的查询效率就会显明比指定字段查询低。
另外，如果表结构发生变动，还会影响到你的应用。