有人说 select * from device d , boiler b where d.device_id = b.boiler_id 不好,认为这会影响性能,问题1: 我想知道影响到底多大,可以量化么?(比如 他的结果将是 100 条记录,每条记录总共 200 个字段,编译一下需多久呢) 问题2:
我想知道怎么处理它,因为我的页面上有些是拼凑的条件,不确定用户将会选择其中的哪些条件,所以用 preparedStatement 我觉得不合适。  有什么方法可以优化它,或者是不是优化可能相对扩展性和灵活性来说不知道呢?

解决方案 »

  1.   

    Question 3 : 是否 对 Column 级权限检查也在编译期间?
    Question 4 : 我这样理解, select 字段只是在最后对所有满足条件的记录做最后的整理发送出去,在我没有使用  decode , case 或其他需要跨列计算(用到当前记录的其他列)的函数时,它不会消耗太多时间。
    CSDN Tips : 怎么给这个贴子加分 ?
      

  2.   

    humanity不搞java老问oracle的问题了.你的问题越来越不好回答了.
      

  3.   

    CSDN Tips : 怎么给这个贴子加分 ?我也想理解为什么有些人能很快爬到 爬行榜 前面去: 如果问么这么久所提的问题档次越来越低怎对得起各位呢?
      

  4.   

    select * 
    数据库根据from tbl_name到字典表中查找该表的所有的字段名,
    如果写成select col_1,col_2,col_3.......
    数据库九省去查询字典表的操作
    因此。。
      

  5.   

    有人说 select * from device d , boiler b where d.device_id = b.boiler_id 不好,认为这会影响性能,
    ----------------------
    我不知道为什么会说这句影响性能.这是最平常的表连接而且都通过主键索引.如果主键索引都效率差就想不出来还有什么更好的连接性能了.如果说的是第4个问题,那就转4.1. 编译一下对于大量字段(并不考虑记录数),可以在session级别做trace,查看parse time elapsed,当然字段多肯定recursive calls要多,时间要慢.2. 拼凑的条件一般来说是没有什么好办法提高效率的,因为每次sql解析都会产生不同的执行计划,造成缓存的cursor得不到重用,也就是说你执行多少次,它就要parse多少次.3.对 Column 级权限检查是在语法解析时对数据字典的检索得到检查的.4. 没太懂什么意思,只能猜测一下,如果select字段在索引上就能得到(比如组合索引,而select字段都是组合索引的字段,那根本就不再需要table access by rowid),当然时间就很短了.反之就只能从索引上找到data block的rowid,再去检索得到其它字段,最后组合起来一起返回客户端.
      

  6.   

    影响性能的原因:ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间.