内容发布更新时间 : 2024/11/1 8:12:03星期一 下面是文章的全部内容请认真阅读。
Informix数据库开发人员指导原则
Version 1.1
一、 目的
1.为提高数据库server运行稳定性和性能、加强数据库安全管理、提高查询和交易效率,特为开发人员制定下列指导原则。
二、 指导原则
A 建库方面
? 在创建数据库时,不能创建在rootdbs上(缺省情况),需要指定dbspace,即创建
在datadbs上:
create database dbname in dbspacename ? 建立数据库应该使用en_us.819字符集
使用缺省DB_LOCALE或设置DB_LOCALE=en_us.819
? 如果有两个或两个以上的datadbs,则要考虑创建在哪个datadbs上。原则是:使每
个datadbs上的数据大小尽量相近,以缩短数据库备份时间。
B 表的使用方面
? 对于新建的每个表,都需要把public用户的权限去除。
为此创建每个新表的sql语句后,需要添加如下语句:revoke all on tablename from \;
每个数据库中的表尽量由同一个用户来创建,这样对于以后权限的控制比较方便。 ? 对于很大的表,可以考虑使用分区表(parition)技术,即把表分布在多个datadbs上,
这样可以提高数据的查询速度。 ? 建立大表的特殊处理
对于大的表,例如记录数达到百万行以上的表,或者是随时间而增大的记录log的表,应该设置大的表first extent,next extent可以设为前者的1/10。extent以page(2K)为单位。如
create table \ (
col1 varchar(80) not null , col2 varchar(20)
) extent size 100000 next size 10000 lock mode page; 这里的extent size 100000指的就是初始extent大小为200M;
next size 10000 指的就是后续增量extent大小20M。
? 临时表的用法
在使用临时表时一定要加with no log,包括create temp table和select into temp两种方式,这些能提高临时表处理的效率,以及减少逻辑日志的使用量。
C 关于数据清理和装载时的注意事项
在一个带日志的数据库中进行大数据量的删除时,尽量不要直接delete。应该将所需要保留的数据先卸载(unload)出来,然后先删除(drop)表,再重新创建表并重新装载(load)数据,否则容易产生长事务及锁资源溢出的问题。
在一个带日志的数据库中进行大数据量的装载时,如果条件许可,可将数据库日志改为不带日志,装载完数据后再将数据库日志重新改为带日志模式。或者在7.31版本以后,可以先将表创建为raw table,在装载完数据后将表改为standard模式(alter table tablename standard),由于raw table不支持索引,所有索引包括主键需在数据装载完毕并改为standard模式后再创建。如果一定要在带日志的情况下装载数据,建议将需要装载的文件切成记录数较少的多个文件,或者使用dbload工具装载,在装载完一定记录后先提交,再继续装载,以防产生长事务。
在进行过数据删除或装载后一定要对表重新进行一次统计更新,以保持系统表信息和实际表信息的同步。
D 统计更新(update statistics)
对经常需要查询修改的表定期进行统计更新,是数据库保持高性能的重要条件。对于那些记录数增长比较快的表也应该定期做低度(low)的统计更新。如果还需要得到更好的查询性能,可对一些表的经常查询用到的索引字段进行高级的统计更新,语法如下:update statistics high for table tablename(col1,col2…); 需要注意的是:不要对整表做高级统计更新,速度会非常慢。
E SQL执行计划和set explain on的使用
不同的sql有可能运行的开销会大不相同,为此,informix提供了set explain的工具供开发人员和数据库管理人员分析一个sql语句的估计开销和查询计划。语法为:在dbaccess内,SQL语句执行添加1行set explain on;(9版本以前)或者set explain on avoid_execute;(9版本以后),informix会在当前目录下生成一个sqexplain.out的文件。文件中的Estimated cost为informix查询计划的预估开销,越小越好。对于缺少经验的应用开发人员,可以先多使用这个工具,以获得不同sql语句之间效率高低的相关知识,从而对以后的编程积累知识。当然,有些时候,数据库会制定出一个错误的查询计划,这在早期版本中比较常见,特别是在表上又多个索引时,有可能会选用一个不适当的索引,导致开销大大增大。另外,经常定期的执行统计更新,也会影响数据库制定查询计划的准确性。
F 锁和脏读
对于经常需要访问修改的表,建议将其锁粒度设置为记录级锁,以减少锁冲突的概率,但是在
做一些批量操作时,如果表的锁模式为记录级锁的话,会大大降低批量的性能,建议如果条件许可的话,在执行此类批量操作时,先对整表上排他锁(lock table in exclusive mode),会大大提高此类批量的性能;另外,建议所有的查询都设置隔离级别为脏读(set isolation to dirty read),这样不会产生因为所查询记录被锁而导致的查询失败。
对于经常需要访问修改的表,建议将其锁粒度设置为记录级锁,以减少锁冲突的概率,但是在做一些批量操作时,如果表的锁模式为记录级锁的话,会大大降低批量的性能,建议如果条件许可的话,在执行此类批量操作时,先对整表上排他锁(lock table in exclusive mode),会大大提高此类批量的性能;另外,建议所有的查询都设置隔离级别为脏读(set isolation to dirty read),这样不会产生因为所查询记录被锁而导致的查询失败。
G Sql编程的一些注意事项
? 对于经常访问的表中字段,建议对其建立索引。并尽量多用索引查询,防止对大表
的seqscan(全表扫描)。
? 尽量多用join连接,少用子查询。 ? 使用join时join字段上必须有索引。
? 使用matches,like时一定要从字段的第一位开始匹配,否则不会用到索引。 ? 在查询条件中如果对字段使用函数,如trim等,不会使用索引。