请问PL/SQL与SQL查询哪个更快！

PL/SQL是一系列SQL语句的组合。
而你只有一条语句就搞定了的，你的情况是用不到它的。
只有从硬件，环境变量还有索引等方面下手。

解决方案 »

  1.   

    应该是索引的问题,在WHERE条件字段中的列没有没有获得索引的支持,数据库进行了全表扫描
    用EXPLAIN PLAN检查一下执行路径先
      

  2.   

    真是谢谢各位了。
    我看了一下EXPLAIN PLAN：QUERY PLANS
    --------------------------------------------------------------------------------
     SELECT STATEMENT   cost=1919
       SORT GROUP BY
         MERGE JOIN
           SORT JOIN
             HASH JOIN
               TABLE ACCESS FULL T_s3
               HASH JOIN
                 TABLE ACCESS FULL T_s4
                 NESTED LOOPS
                   INDEX FULL SCAN PK_T_f1
                   PARTITION RANGE ITERATOR
                     INDEX RANGE SCAN PK_T_a
           FILTER
             SORT JOIN
               TABLE ACCESS FULL T_s2这里，数据量最大的T_a已经被INDEX RANGE SCAN。还有什么好招吗？
      

  3.   

    可惜，这种查询每次都不一样。但是我的竞争对手好象是用ACCESS，他居然只要25秒。也许应该从表结构上想办法了。但是，目前的数据量已经够大了，用空间换时间也许更不可取！每次查询都很不一样，如果要保存查询的结果，做成数据仓库会有TB级。真是伤脑筋。
      

  4.   

    PARTITION RANGE ITERATOR
    已经有分区了。问题的关键在于符合条件的记录数超过30万条，有时甚至会超过400万条。真诚的谢谢大家，请再帮帮我！
      

  5.   

    还有哪位高手可以帮我！所有的表都被分析过，T_a是索引组织表，所以，SQL语句无论这样写ORACLE都会按照基于成本的优化。
      

  6.   

    pausing(select 人生 from data),怎么回是PL/SQL快列，PL/SQL最终也是以SQL执行的！
      

  7.   

    就是，四年前我写PL/SQL写得发酸，那时候的小型机还没有我现在的便携机快。在我印象里，PL/SQL慢得简直是场噩梦！
    可是四年没写了，有点手生，有点好了伤疤忘了疼。我被这个该死的速度害惨了，有点病急乱投医。但是我仍然抱有一点幻想：
    如果用PL/SQL，那么我只要对T_a进行一次INDEX RANGE SCAN ，不用做很多次
    HASH JOIN。是不是有道理呢？！唉，还是不能偷懒！等我写完PL/SQL再同大家讨论吧！
    有愿意帮我写的人吗？我愿意给500分，当然要没有错误才行！还可以还价呀！不过一定要快！