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语句时应该注意的一些问题阐述一下笔者的观点,不当之处还请大家批评指正。