PLSQL调优.doc

一、PL/SQL性能问题的原由 当基于PL/SQL的应用程序执行效率低下时，通常是由于糟糕的SQL语句、编程方法，对PL/SQL基础掌握不好或是滥用共享内存造成的。 PL/SQL中糟糕的SQL语句 PL/SQL编程看起来相对比较简单，因为它们的复杂内容都隐藏在SQL语句中，SQL语句常常分担大量的工作。这就是为什么糟糕的SQL语句是执行效率低下的主要原因了。如果一个程序中包含很多糟糕的SQL语句，那么，无论PL/SQL语句写的有多么好都是无济于事的。 如果SQL语句降低了我们的程序速度的话，就要按下面列表中的方法分析一下它们的执行计划和性能，然后重新编写SQL语句。例如，查询优化器的提示就可能会排除掉问题，如没有必要的全表扫描。 EXPLAIN PLAN语句 使用TKPROF的SQL Trace功能 Oracle Trace功能 不好的编程习惯 通常，不好的编程习惯也会给程序带来负面影响。这种情况下，即使是有经验的程序员写出的代码也可能妨碍性能发挥。 对于给定的一项任务，无论所选的程序语言有多么合适，编写质量较差的子程序(例如，一个很慢的分类或检索函数)可能毁掉整个性能。假设有一个需要被应用程序频繁调用的查询函数，如果这个函数不是使用哈希或二分法，而是直接使用线性查找，就会大大影响效率。不好的程序指的是那些含有从未使用过的变量的，传递没有必要的参数的，把初始化或计算放到不必要的循环中执行的程序等等。 内置函数的重复 PL/SQL提供了许多高度优化过的函数，如REPLACE、TRANSLATE、SUBSTR、INSTR、RPAD和LTRIM等。不要手工编写我们自己的版本，因为内置函数已经是很高效的了。即使内置函数的功能远远超过我们的需要，也不要手工实现它们功能的子集。 低效的流程控制语句 在计算逻辑表达式值的时候，PL/SQL使用短路的计算方式。也就是说，一旦结果可以被确定下来，PL/SQL就会停止剩余的表达式计算。例如，下面的OR表达式，当sal比1500小的时候，操作符左面的值就是TRUE，所以PL/SQL就不会再计算操作符右边表达式的值： IF (sal 1500) OR (comm IS NULL) THEN ... END IF; 现在，思考下面的AND表达式： IF credit_ok(cust_id) AND (loan 5000) THEN ... END IF; 在上面的函数中，布尔函数credit_ok总是被调用。但是，如果我们向下面这样调换两个表达式的位置： IF (loan 5000) AND credit_ok(cust_id) THEN ... END IF; 那么，函数只有在表达式loan 5000的值为TRUE的时候才会被调用，这种情况也适用于EXIT-WHEN语句。 隐式的数据类型转换 运行时，PL/SQL能把结构化不同的数据类型进行隐式的转换。比如说，把PLS_INTEGER变量赋给一个NUMBER变量，由于它们的内在表现形式不一样，所以就会引起隐式地数据类型转换。 避免隐式的类型转换可以改善性能。如下面的例子，15是一个有符号的4字节数字，在加法运算之前，PL/SQL必须把它转换成Oracle的数字类型。但是，浮点数15.0使用22字节的Oracle数字表现，所以就没有必要进行转换。 DECLARE n NUMBER; c CHAR(5); BEGIN n := n + 15; -- converted n := n + 15.0; -- not converted ... END; 这里还有一个例子： DECLARE c CHAR(5); BEGIN c := 25; -- converted c := 25; -- not converted ... END; 不适当的数字类型声明 数据类型NUMBER和它的子类型都是22字节，数据库格式的数字，它们便于移植并且能适应于不同的长度与精度。当我们需要声明一个整型变量时，就要使用PLS_INTEGER，它是最高效的数字类型。这是因为PLS_INTEGER所需的内存要比INTEGER和NUMBER类型要少。同样，PLS_INTEGER使用机器运算，所以它的运算速度要比BINARY_INTEGER、INTEGER或NUMBER快得多。 此外，INTEGER、NATURAL、NATURALN、POSITIVE、POSITIVEN和SIGNTYPE都是受约束的子类型。所以，它们的变量需要在运行时检查精度，这就会影响到效率。 不必要的NOT NULL约束 PL/SQL中，使用NOT NULL约束也能导致性能损耗。如下