通过jdbc执行sql比在plsql中慢好多

以下是我的SQL语句，表上的数据量有40多万。
SELECt SUM (T032_FORM_SU) FROM T029_FORWARD_SIJI T029 INNER JOIN T032_FORWARD_SIJIM ON
T029_WAREH_CD = T032_WAREH_CD
AND T029_OWNER_CD = T032_OWNER_CD
AND T029_SHIPMENT_ID = T032_SHIPMENT_ID
AND T032_TRAN_KBN < '3'
WHERe
T029_WAREH_CD = ?
AND T029_OWNER_CD = ?
AND T029_SLIP_KBN <> '4'
AND T029_SLIP_KBN <> '5'
AND T029_SLIP_KBN <> '9'
AND T029_SHIPMENT_KBN = '01' AND T029.T029_TRAN_KBN < '3'
通过jdbc动态绑定参数执行要10多秒才能完成，但是如果在plsql中执行，条件直接付值，也就是0.1秒左右就好了。不知道这是什么问题，而且通过jdbc执行时，如果不动态绑定参数，直接付值的话也非常快，就是一动态绑定参数，就慢了，这是什么原因。
t029是主表，t032是明细表。 这两个表都建有索引。

结果只一条数据

--重点在于使用了绑定变量，详解如下：

使用绑定变量，这是导致性能问题的一个主要原因，也是阻碍可扩缩性的一个重要因素。

开发人员在大多数情况下都会使用绑定变量。如果你确实想让Oracle 缓慢地运行，甚至几近停顿，只要根本不使用绑定变量就可以办到。
绑定变量（bind variable）是查询中的一个占位符。例如，要获取员工123 的相应记录，可以使用以下查询：
select * from emp where empno=123;
或者，也可以将绑定变量:empno 设置为123，并执行以下查询：
select * from emp where empno=:empno;
在典型的系统中，你可能只查询一次员工123，然后不再查询这个员工。之后，你可能会查询员工456，然后是员工789，如此等等。如果在查询中使用直接量（常量），那么每个查询都将是一个全新的查询，在数据库看来以前从未见过，必须对查询进行解析、限定（命名解析）、安全性检查、优化等。简单地讲，就是你执行的每条不同的语句都要在执行时进行编译。
第二个查询使用了一个绑定变量:empno，变量值在查询执行时提供。这个查询只编译一次，随后会把查询计划存储在一个共享池（库缓存）中，以便以后获取和重用这个查询计划。
以上两个查询在性能和可扩缩性方面有很大差别，甚至可以说有天壤之别。
从前面的描述应该能清楚地看到，与重用已解析的查询计划（称为软解析，soft parse）相比，解析包含有硬编码变量的语句（称为硬解析，hard parse）需要的时间更长，而且要消耗更多的资源。硬解析会减少系统能支持的用户数，但程度如何不太明显。这部分取决于多耗费了多少资源，但更重要的因素是
库缓存所用的闩定（latching）机制。硬解析一个查询时，数据库会更长时间地占用一种低级串行化设备，这称为闩（latch）。这些闩能保护Oracle 共享内存中的数据结构不会同时被两个进程修改，而且如果有人正在修改数据结构，则不允许另外的人再来读取。对这些数据结构加闩的时间越长、越频繁，排队等待闩的进程就越多，等待队列也越长。你可能开始独占珍贵的资源。有时你的计算机显然利用不足，但是数据库中的所有应用都运行得非常慢。造成这种现象的原因可能是有人占据着某种串行化设备，而其他等待串行化设备的人开始排队，因此你无法全速运行。数据库中只要有一个应用表现不佳，就会严重地影响所有其他应用的性能。如果只有一个小应用没有使用绑定变量，那么即使其他应用原本设计得很好，能适当地将已解析的SQL 放在共享池中以备重用，但因为这个小应用的存在，过一段时间就会从共享池中删除已存储的SQL。这就使得这些设计得当的应用也必须再次硬解析SQL。真是一粒老鼠屎就能毁了一锅汤。

正确

大哥，plsql是只检索出前面的20条，即rownum<20 的数据，JDBC是查全部。你把PLSQL的数据全展开，你看看要多少秒！

如以上回答内容为低俗、色情、不良、暴力、侵权、涉及违法等信息，可以点下面链接进行举报！

点此我要举报以上问答信息