SQL语句优化DB2应用程序性能（四）

yes-no

　　6、指定FOR FETCH ONLY子句
　　　如果不想更新那些由SELECT语句提取的行，我们可以在SELECT语句中指定FOR FETCH ONLY子句，这么做的好处是，处理应用程序提出的查询请求时可以充分利用行的分块技术，进而改善性能;该子句还能改善数据的并发性，因为使用该子句查询的那些行上不再有独占的锁了。除了FOR FETCH ONLY子句，我们还可以使用FOR READ ONLY子句，二者是同义词，功效一致。
　　7、避免数据类型转换
　　我们应尽可能地避免数据类型的转换，特别是数字的数据类型之间的转换。当比较两个值时，使用具有相同数据类型的项目进行比较效率会更高。例如，有两张表：A和B，使用A的A1列和B的B1列进行两表间的连接操作，如下所示：

SELECT * FROM A，B  WHERE A1=B1

　　
　　如果列A1和B1的数据类型一致，则无需进行数据类型转换;如果不一致，那么，应用程序就会在运行时进行数据类型的转换以比较二者的数值大小，从而影响应用程序的性能。例如，如果A1列的数据类型是decimal，而B1是integer，并且都有一个数值“123”，那么这时就需要进行数据类型转换了，因为表A将“123”存储为“123C”(十六进制表示)，而表B存储为“7B”(十六进制表示)。
　　再者，进行数据类型转换时，由于计算精度的限制，可能会导致错误的发生。
　　DB2 UDB提供许多数据类型，其中，有用于数字数据的SMALLINT，INTEGER，BIGINT，DECIMAL，REAL，DOUBLE;有用于字符数据的CHAR，VARCHAR，LONG VARCHAR，CLOB;也有用于双字节字符数据的GRAPHIC，VARGRAPHIC，LONG VARGRAPHIC和DBCLOB，等等。由于数据库的存储容量和各种变量的处理成本都取决于数据类型，所以，我们在编程时如何选择适当的数据类型就显得十分重要，以下是选择数据类型时应该遵循的一些准则：
　　● 对于比较短的列，尽量使用定长的CHAR而不是变长的VARCHAR。虽然，当数据的长度参差不齐时，VARCHAR可以节省数据库存储空间，但是系统需要花费额外的开销去检查每个数据的长度。
　　● 尽量使用VARCHAR或VARGRAPHIC而不是LONG VARCHAR或LONG VARGRAPHIC。VARCHAR列和LONG VARCHAR列的最大长度差不多，基本一致，VARCHAR列的最大长度是32672字节，LONG VARCHAR列的最大长度是32700字节;同样地，VARGRAPHIC列和LONG VARGRAPHIC列的最大长度也相仿，VARGRAPHIC是16336字节，LONG VARGRAPHIC是16350字节。对于LONG VARCHAR列和LONG VARGRAPHIC列有一些限制，比如，这两列中的数据不能存储在数据库缓冲池中。
　　● 如果不需要小数部分，则尽量使用整数(SMALLINT，INTEGER，BIGINT)而不是浮点数(REAL或DOUBLE)或十进制数(DECIMAL)。比较而言，整数的处理成本要廉价得多。
　　● 尽量使用日期--时间(DATE，TIME，TIMESTAMP)而不是字符(CHAR)。日期--时间数据类型会占用较少的数据库存储空间，而且，对于日期--时间数据类型的变量，我们还可以利用系统提供的一些内置函数(如YEAR，MONTH)对其进行计算、转换等处理，一般来说，内置函数要比我们手工编写的函数在性能、效率上都要高一些。
　　● 尽量使用数字的数据类型而不是字符的数据类型。
　　凡事都是一分为二，有利有弊的，我们不能既想节省数据库的存储空间，又希望降低应用程序的处理成本，二者只能取其一，不可兼得，这就要求我们在编程时不能仅局限于一点，应该通盘考虑整个应用程序的设计，综合评估，权衡利弊，以求应用程序的性能更优。
　　结束语
　　一谈起数据库性能调整、优化，我们脑海中往往就会有这样的概念：优化是系统维护时做的事情，属于后期制作。其实不然，早在编程时就已经存在性能优化的问题了。本文就编写SQL语句时应该注意的一些问题阐述一下笔者的观点，不当之处还请大家批评指正。