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等，不会使用索引。