数据库设计经验之--存储过程编写

lexinquan

1、数据库访问，最好全部固化成存储过程，保存在数据库中。同时尽量不使用trigger机制，难以管理及查错。

2、数据库操作时，仅选择有用列。除非有充足理由，不应该出现select * 的形式。

3、存储过程中尽量少用会引起存储过程重新编译的脚本，例如：动态sql语句、临时表、DDL语句。

4、以DB2为例，只读操作加上for fetch(read) only，如果只需要检索结果的几个，可以加上order by，fetch first x rows语句。

5、存储过程尽量精简，只实现简单IO，业务逻辑编放在中间层实现。

6、对于多个小更新操作，可以把所有更新放入一个批处理中，避免多次提交。

7、对于大事务，要尽快提交，提高数据库的并发性。与数据操作无关的语句不要放在事务中进行，特别是在开发分布式应用程序时尤其要注意。

8、每个数据库产品都会提供不同隔离级别的访问方式，以适应不同的并发性要求。在做实时查询时，如果可以，尽量用不加锁的访问方式，如SQLServer中的WITH(NOLOCK)表提示，DB2中的WITH UR，甚至可以把这当成编程规范（除非必须加锁时），提高并发性。

9、实时应用程序要加快用户操作响应，当数据库查询较慢时可以在界面有互动，或先返回部分数据给前台操作用户，或在数据库中先做一些预计算以备查询。

10、存储过程中尽量不要使用游标，使用集合操作方式。

11、存储过程中的SQL查询过滤条件太多，导致数据库负载增加，影响性能。可以适当考虑修改SQL查询，只通过索引访问数据库，再通过应用层进行条件过滤。

12、尽量少用模糊查询，由于like本身效率就比较低，应该尽量避免查询条件使用like。由于匹配算法的关系，模糊查询的字段长度越大，模糊查询效率越低。可通过索引访问数据后，再进行过滤。

13、考虑不等号操作符可能会引起全表扫描。可通过使用索引，将不等号改成用OR实现。如 id<>‘C’改为 id<’C’ or id>’C’，这样就能使用索引。（注：目前有些数据库查询优化器能自动优化，可以查看具体执行计划）

14、考虑 NOT IN 会导致产生笛卡尔积，使得访问效率低下。可以通过左外连接方式（Ta.C1 = Tb.C1）并加上 Tb.C1 is null 来处理。（注：目前有些数据库查询优化器能自动优化，可以查看具体执行计划）

15、如果怀疑SQL语句有性能问题，一定要用解释工具检查其执行成本。

16、注意进行数据库统计优化操作，有利于数据库查询优化器自动优化访问计划。