SQL执行并发时相当的慢。

Question

我遇到一个奇怪的问题，发现在并发时执行很慢。贴上相关信息。这是在我一个session连接时操作的详细记录：
SQL> SELECT count(*)
  2    FROM (select *
  3            from v_rd_record t
  4           where 1 = 1
  5             AND (t.VEN_CODE like '%A1093%')
  6             AND (t.ORG_ID = '2')) totalTable;已用时间:  00: 00: 17.07Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=42 Card=1 Bytes=188)
   1    0   SORT (AGGREGATE)
   2    1     NESTED LOOPS (Cost=42 Card=210 Bytes=39480)
   3    2       HASH JOIN (Cost=42 Card=343 Bytes=62083)
   4    3         TABLE ACCESS (FULL) OF 'SRM_VENDOR_ORG' (Cost=38 Car
          d=567 Bytes=5670)   5    3         NESTED LOOPS (Cost=3 Card=343 Bytes=58653)
   6    5           INDEX (UNIQUE SCAN) OF 'PK_SRM_SUBSIDIARY' (UNIQUE
          )   7    5           TABLE ACCESS (BY INDEX ROWID) OF 'SRM_RDRECORD' (C
          ost=2 Card=1 Bytes=168)   8    7             INDEX (RANGE SCAN) OF 'RD_SUB_FK' (NON-UNIQUE) (
          Cost=1 Card=13726)   9    2       INDEX (UNIQUE SCAN) OF 'PK_SRM_VENDOR' (UNIQUE)
Statistics
----------------------------------------------------------
          7  recursive calls
          0  db block gets
      69867  consistent gets
      38749  physical reads
          0  redo size
        377  bytes sent via SQL*Net to client
        503  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed这是我在并发10-15个session以后的执行情况：
SQL> SELECT count(*)
  2    FROM (select *
  3            from v_rd_record t
  4           where 1 = 1
  5             AND (t.VEN_CODE like '%A1093%')
  6             AND (t.ORG_ID = '2')) totalTable;已用时间:  00: 01: 11.01Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=42 Card=1 Bytes=188)
   1    0   SORT (AGGREGATE)
   2    1     NESTED LOOPS (Cost=42 Card=210 Bytes=39480)
   3    2       HASH JOIN (Cost=42 Card=343 Bytes=62083)
   4    3         TABLE ACCESS (FULL) OF 'SRM_VENDOR_ORG' (Cost=38 Car
          d=567 Bytes=5670)   5    3         NESTED LOOPS (Cost=3 Card=343 Bytes=58653)
   6    5           INDEX (UNIQUE SCAN) OF 'PK_SRM_SUBSIDIARY' (UNIQUE
          )   7    5           TABLE ACCESS (BY INDEX ROWID) OF 'SRM_RDRECORD' (C
          ost=2 Card=1 Bytes=168)   8    7             INDEX (RANGE SCAN) OF 'RD_SUB_FK' (NON-UNIQUE) (
          Cost=1 Card=13726)   9    2       INDEX (UNIQUE SCAN) OF 'PK_SRM_VENDOR' (UNIQUE)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      69865  consistent gets
      38820  physical reads
          0  redo size
        377  bytes sent via SQL*Net to client
        503  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed从执行情况我看不出来哪有什么问题啊，请各位达人帮帮我，急死了。
另外执行计划中出现了table full这样的现象正确吗？

Answer 1

select * 
from v_rd_record t 
where t.VEN_CODE like '%A1093%' 
AND t.ORG_ID = '2'你那個為啥還要套一層呢？  這樣也能滿足吧

Answer 2

暈     忘加上count了~~

Answer 3

怎么没人解决呢？我试了很多语句，发现只要有并发的seesion存在，时间就会变长，这是正常的现象吗？

Answer 4

TABLE ACCESS (FULL) 可能根据表 SRM_VENDOR_ORG中的数据量，如果数据量较少，即使有索引，也是不会用的，如果10-15个用户同时在执行相同的语句，性能会有明显的下降

Answer 5

我试了试执行其他的语句，比如说select count(*) from table_name; 在一个session查时只有0.几秒。但session并发更多的时候，查询就会增加到几秒，有明显的时间过长。