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

kingofworl 2009-03-29 10:48:42
直接select * 会导致解析table的定义字典,
但例如: select * from (select empno,deptno from emp)
在这种情况下使用select * 还会有解析的问题吗,会降低性能吗?
...全文
621 23 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
23 条回复
切换为时间正序
请发表友善的回复…
发表回复
chogo 2009-04-01
  • 打赏
  • 举报
回复
select * 这样的东西一般来讲跟执行计划无关,也就是说从索引定位到数据的效率是一样的(如果只查询索引列另计)。
但是select *会产生解析数据字典、并且夸张点说,如果你的这个表有200个字段,其中又有一些是CLOB什么的,那么这样的查询效率就会显明比指定字段查询低。
另外,如果表结构发生变动,还会影响到你的应用。
merrill 2009-03-31
  • 打赏
  • 举报
回复
当然如果直接些 select 字段名。。。 那么是比 select * 好
merrill 2009-03-31
  • 打赏
  • 举报
回复
[Quote=引用 13 楼 LJY_AINILU 的回复:]
引用 4 楼 jiewo 的回复:
*,不是决定性能的主要问题。
如果你的sql语句性能优问题,那么你应该从你的子查询的优化开始·


为什么是有限
从哪里看出来影响性能有限?
如果数据量大的话还会是有限么
我感觉要是数据量大的话影响应该不小
[/Quote]
select * 多了层sql的递归调用 去解析数据字典表 获得各个字段
因此我觉得是很有限的
希望和大家讨论下
多壮志 2009-03-31
  • 打赏
  • 举报
回复
参考书中关于recursive calls的地方看看-主要消耗的是CPU 。
kingofworl 2009-03-31
  • 打赏
  • 举报
回复
谢谢大家的讨论 其实我主要想问的是
select * from (select empno,deptno from emp)
相比
select empno,deptno from (select empno,deptno from emp)
有没有性能下降,如果有,怎么能分析出来,执行计划似乎看不出来吧
Angly1018 2009-03-31
  • 打赏
  • 举报
回复
学习
hjm1981 2009-03-31
  • 打赏
  • 举报
回复
解释计划也不能全信,有时也可能不正确。
个人认为能不用*,最好不用,性能更定不全差。
dinya2003 2009-03-31
  • 打赏
  • 举报
回复
首先基于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秒就完成了,我们就感觉不到了).
多壮志 2009-03-31
  • 打赏
  • 举报
回复
就你这个情况,那么只有一点点.................!
最终oracle,会解析成为另外一个sql.
dinya2003 2009-03-31
  • 打赏
  • 举报
回复
各位是怎么得出好还是不好的结论的呢?

specialco 2009-03-30
  • 打赏
  • 举报
回复

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 415141292

select * from (select * from srcs.cm_user)的解析
SELECT STATEMENT, GOAL = ALL_ROWS 13272 2485876 415141292
TABLE ACCESS FULL SRCS CM_USER 13272 2485876 415141292

从上面的代码的解析来看,没有影响吧,有人有其它的测试吗?
Andy__Huang 2009-03-30
  • 打赏
  • 举报
回复
如果没有了其他条件,我认为不会影响
又是违规昵称 2009-03-30
  • 打赏
  • 举报
回复
不好意思,看错了,
会影响性能,但是有限
又是违规昵称 2009-03-30
  • 打赏
  • 举报
回复
不仅仅会影响性能,而且有一天数据库变动,比如表加了一列,应用就会出错

这种写法建议不用
白发程序猿 2009-03-30
  • 打赏
  • 举报
回复
没必要就不要加
jdsnhan 2009-03-30
  • 打赏
  • 举报
回复
肯定会,数据量越大越明显
LJY_AINILU 2009-03-30
  • 打赏
  • 举报
回复
[Quote=引用 4 楼 jiewo 的回复:]
*,不是决定性能的主要问题。
如果你的sql语句性能优问题,那么你应该从你的子查询的优化开始·

[/Quote]
为什么是有限
从哪里看出来影响性能有限?
如果数据量大的话还会是有限么
我感觉要是数据量大的话影响应该不小
「已注销」 2009-03-30
  • 打赏
  • 举报
回复
mark
yf520gn 2009-03-29
  • 打赏
  • 举报
回复
影响有限,但是能不要还是别要
行舟 2009-03-29
  • 打赏
  • 举报
回复
*,不是决定性能的主要问题。
如果你的sql语句性能优问题,那么你应该从你的子查询的优化开始·
加载更多回复(3)

17,140

社区成员

发帖
与我相关
我的任务
社区描述
Oracle开发相关技术讨论
社区管理员
  • 开发
  • Lucifer三思而后行
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧