设计优质高效地Informix数据库运用程序

INFORMIX数据库是一被广泛应用的关系型数据库，如何提高其应用性能是大家关心的话题，特别是随着数据库中数据量与应用处理交易量的不断增多，其运行效率问题尤显突出。

众所周知，数据库应用系统的性能优化是一个高度复杂，异常繁琐而且涉及面很广的综合性工作。面对复杂的数据库应用系统性能调优，大家往往感到无从下 手。其实对性能调优不外乎从网络、硬件、操作系统、数据库参数和应用程序等方面来考虑。事实上，对网络、硬件、操作系统、数据库参数进行优化所获得的性能 提升全部加起来只占数据库应用系统性能提升的40%左右，其余的60%系统性能提升全部来自对应用程序的优化。

本文结合工作实践，从INFORMIX ONLINE参数的配置和性能调整、数据库表创建的方式、索引策略、查询语句(SELECT)优化等方面对INFORMIX数据库应用系统的程序设计和数据维护提出一些优化措施。

一、 INFORMIX ONLINE参数设置的优化措施

INFORMIX数据库系统参数性能调整的优劣直接影响INFORMIX数据库运行效率。在决定进行系统性能调优时，首先应制定一个完整的调优方 案，先监控系统并分析出问题所在，然后根据分析结果每次调整一个参数，再进一步监控系统查看系统性能有无变化，然后再做近一步的调节。其中有一个重要的原 则：每次最好只调节一个参数。

数据库系统性能通常与磁盘I/O、CPU、共享内存和网络四个方面有关。至于此四个方面在性能调优中孰轻孰重，还要根据整个系统的实际情况具体问题具体分析。

1、磁盘I/O

对磁盘调整的原则是降低读盘次数，极大化每次读盘数据量，数据分布均匀，防止瓶颈的发生。INFORMIX ONLINE的磁盘空间应采用裸设备方 式(raw  device)，而不应采用经过加工的文件空间(cooked  file space)，前者比后者处理速度要快得多，且可靠性高。影响 磁盘I/O的几个ONLINE配置参数：

◆ CKPTINTVL：该参数指定检查点（CheckPoint）之间的时间间隔。

◆ PHYSFILE：物理日志的大小建议为整个日志空间的25%。即：物理日志空间大小：逻辑日志空间大小=1：3

◆ LRUS：该参数指示共享内存缓冲池中设置的最近最少使用队列数目。配置较多的LRU队列将允许有更多的页清除器操作，并减少每个LRU队列的大小。对于 单CPU系统，INFORMIX建议设置LRUS参数为最小值4。对于多CPU系统，INFORMIX建议设置LRUS为最小值4和NUMCPUVPS的 取值之中较大的一个。

◆ CLEANERS：该参数指定执行的页清除线索的数目。

参考下表：

磁盘个数 INFORMIX推荐的CLEANERS值

　＜２０ 磁盘的个数

２０－１００ 磁盘的个数／２

＞１００ 磁盘的个数／４（不超过128）

2、CPU

INFORMIX动态数据库服务器对CPU的处理采用先进的多进程多线索机制，即使用了VP(virtual  processer 虚处理器)去 管理物理CPU资源，均衡CPU负载，其中对性能影响较大的是CPU VP。我们可以把CPU VP看成是搭构在物理CPU之上的由INFORMIX动态 服务器自己管理的虚CPU，因此物理CPU对用户而言是透明的。

CPU VP是一个多线索进程，除了没有任务做，例如就绪队列中没有等待执行的线索或操作系统强迫CPU VP让出CPU 给其它进程，它将一直在CPU上执行。

为优化吞吐量，将NUMCPUVPS设置为能够处理承接任务的最小的数，这个数目小于或等于系统中可利用的CPU数，建议不要将CPU VP数设置 成大于可用CPU数目。通常对于联机事务处理（OLTP）应用：NUMCPUVPS＝实际CPU数量－1（对于单ＣＰＵ系统，该参数应为１）；对于联机分 析处理（OLAP）应用：NUMCPUVPS＝实际CPU数量。

如果CPU VP不能承受要执行的任务，这就表示需要提高CPU性能来解决问题。只有存在另外的处理器，才能通过增加CPU VP来解决问题。也可以从系统上移走其它任务，为虚处理器释放CPU周期，从而改善性能。

增加CPU VP的数目而不增加CPU资源只会使问题更严重，产生更多的CPU周期竞争，这样操作系统要有更多的工作来做均衡，争夺CPU时间的CPU VP使其负担增加。结果，上下文切换增加，这不仅消耗时间而且要使用更多的CPU。

3、共享内存（Shared Memory）

当调整系统性能时，对于内存的调节要考虑两方面的问题：

◆ 是否有足够的物理内存？

◆ INFORMIX  ONLINE的共享内存配置是否合理？是否充分使用了物理内存？

INFORMIX ONLINE共享内存分为三部分：驻留部分、虚处理部分和消息部分，其中消息部分只有在客户机和服务器采用共享内存方式连接时才有。

可以通过对INFORMIX 共享内存的虚处理部分来看系统是否有足够的物理内存。当前的操作系统和数据库系统都只有一小部分的数据和过程处理在内 存中，这一小部分数据页被称之为进程工作组(working  set)。当一个进程工作组改变或其它进程运行时，每个进程工作组需要的内存也许会超出实 际内存的容量。这时，一些数据页将被移出实际内存，其它的数据页将被移入。

影响共享内存的几个ONLINE配置参数：

◆SHMVIRSIZE：该参数规定了初始分配给ONLINE的共享内存的虚拟区的大小。共享存储器的虚拟区存储与会话、请求有关的数据及其它信 息。虽然ONLINE按处理大型查询或高峰负荷的需要增加共享内存给虚拟区，但共享内存的分配增加事务处理的时间，INFORMIX建议设置 SHMVIRTSIZE以提供一个满足一般日常操作需要的虚拟接口。一般50用户设8000KB，100用户设16000KB。

◆SHMADD：该参数规定ONLINE自动加到虚拟区的共享内存增量的大小。在决定该值的大小时有些折中因素。增加共享内存要占用CPU周期：每 次的增加量越大，增加次数就越少，留给其它的进程的内存也越少。通常采用大增加量，但当内存负荷很重时，少量增加使其他程序更好的共享内存资源。 INFORMIX 有如下建议：

实际内存大小     建议SHMADD值

<=256MB         8192KB(缺省)

256－512MB   16,384KB

>=512MB       32,768KB

◆BUFFERS：该参数可以用于ONLINE的数据缓冲区数。这些缓冲区驻留在驻留区，用来缓存主存中的数据库的数据页。可用的缓冲区越多，所需 的数据页就越可能用于前一次请求而已经在内存里。这个参数对数据库I/O和事务处理吞吐量有明显的影响。但是，分配过多的缓冲区会影响内存系统并导致过多 的页面活动。

INFORMIX建议设置BUFFERS为物理内存(以MB为单位)的20%到25%。实际BUFFERS的单位为页，不同操作系统的页大小是不同的，因此需要计算。

◆LOCKS：该参数设置任意时刻可用的锁的最大数量。ONLINE中每个锁需要占用驻留共享内存的44个字节，分配共享内存时要考虑锁所用的资源。一般锁可以分配的大些，其范围为：2000至8000000个。

◆LOGBUFF：该参数指定为三个用来保存逻辑日志记录的缓冲区分别保留的共享内存的数量。这些缓冲区保存着逻辑日志记录，直到它们被刷新到硬盘 上的逻辑日志文件。缓冲区的大小决定了它被添满的频率，从而决定了它必须被刷新到硬盘上的逻辑文件中的频率。INFORMIX建议设置为16KB或 32KB，对于繁忙的应用，可考虑设置为64KB。

◆PHYSBUFF：该参数指定为两个用来暂时保存将被修改的数据页的缓冲区分别保留的共享内存的数量。缓冲区的大小决定了它被添满的频率，从而也决定了它被写到硬盘上的物理日志的频率。最小值为1个页大小，INFORMIX建议16个页大小。

对于OLTP和OLAP系统，INFORMIX ONLINE共享内存的配置和调节有很大不同。

OLTP应用，驻留部分占共享内 存的很大部分。基本上驻留部分的缓冲池占物理内存的20%至25%。例如，一个RS/6000机器的物理内存为1024MB，初始应将BUFFER的数目 设为（1024MBＸ20％）／4KB＝52428（AIX系统每页大小为4KB）；然后继续增加BUFFER的数目直到读caching到95%，写 caching达到85%，或系统开始增加数据移出(Page  out)。注意：高cache速率意味着磁盘I/O的减少。

如果是OLAP系统，其典型特征是少量的用户读取大量的数据。这样的操作将会导致共享内存池的持续增长，例如排序池和哈希函数池，这些池存在于共享内存的虚处理部分： 在优化OLAP系统时，虚处理部分的大小应设为物理内存的75%，通过参数SHMVIRTSIZE设置。

4、网络

避免网络拥塞的方法之一是减少网络传输量，或将部分传输量移至别处。下列是减少网络传输量的一些措施。

（1）、配置多张网卡

通过设置有关的定义TCP/IP连接的系统文件，INFORMIX ONLINE可在多个网卡间通讯。下列介绍在UNIX系统下的ONLINE配置的步骤：

◆  在/etc/services文件中为每一网卡加入一项：

info21    6621/tcp

info22    6622/tcp

◆  使用不同的IP地址，为本机的每一网卡在/etc/hosts文件中加入一项：

66.77.9.79  rsibm21

66.77.9.80  rsibm22

◆  在INFORMIX用户下$INFORMIXDIR/etc/sqlhosts文件中为每一网卡加一项：

server21  onsoctcp  rsibm21  info21

server22  onsoctcp  rsibm22  info22

◆  在INFORMIX的onconfig文件中，设置参数：

DBSERVERNAME        server21

DBSERVERALIASES    server22

配置完毕后，应用程序可通过指定sqlhosts项的名称或使用环境变量INFORMIXSERVER指定的缺省数据库服务器名称选择某一通往数据库服务器的路径。

（2）、编程方面的考虑

下面是一些能降低网络传输量的编程技术：

◆ 对有成组SQL语句的任务，使用存储例程，因为它们能减少消息的数量和长度。维护数据库的相对完整性，而非将它编码于应用程序中，也能减少网络传输量。

◆ 只返回应用程序需要的数据，筛选所有非必要的行和列。

◆ 在发送与接收数据时，使用传送缓存。

（3）、不同UNIX供应商对TCP/IP参数提供不同级别的控制，以下是可以对性能起作用的参数：

◆ 流式缓冲区的数目。对于客户机/服务器的高负载，多一些缓冲区可以改善性能。

◆ 数据包（Packet）的大小。DSS适用一较大值，一般OLTP用较小值更好。

 

二、 数据库、表创建方式的优化

在数据库建模初期应该充分考虑创建库表的策略。若等到程序设计好之后，再改动库表结构则需要修改程序，这样在时间成本和风险上代价是很高的。

1、建数据库的日志方式

◆ No Logging：不能进行事务处理。

◆ Buffered Log：共享缓存满即刷新写入磁盘。

◆ Unbuffered Log：当一个交易完成时即刷新写入磁盘。

一般我们对实时处理系统日志方式采用Unbuffered Log，在进行大批量数据集中Load或Unload处理时采用No Logging。

2、对数据表空间分配的优化

数据库由表构成，实际运用中，表是动态变化的，并且有的表增长的很快。当一个表在dbspace中有超过8个交错区间时，就会影响其访问效率，随着 交错区间的进一步增多，甚至会恶化成为访问数据库的瓶颈，经常出现系统颠簸现象。具体表现为运行响应时间减慢、备份时间延长，磁盘I/O常居高不下。

通常，一个dbspace有多个chunk，然而并非所有的chunk都得到合理分配，往往是有的chunk根本没用到（因为最初创建数据库时一般 会分配充裕的空间），有的chunk中却拥挤不堪、数据表严重交错。为了平衡I/O，提高访问效率，可以将增长较快的表放入单独的一个chunk中。

在实际设计中，对于大数据量（一般>1MB）并且数据增长快速的表，在使用SQL语句Create Table时可以带 extent size extent－size和next size next－size两参数，前者指定创建表的初始区间大小，后者指定当初始区间充 满后，扩展区间的大小，单位是KB。

在建表前将数据库每张表数据量大小作一估算，以便将表的第一个“extent”（物理上连续的页）空间分配尽量和估算值大小一致，下一个“extent”空间分配则根据表数据的增加量估计值来分配，这样可减少数据分配碎片和空间浪费，提高数据库系统的效率。

例如：

Create Table Test

(policyNo  Char(10)，

　 insuredName   Char(20)

　)

　extent size 100000

　next size 500

该语句建立表test的初始空间有100MB，如数据充满后每次再分配500KB的空间。

3、采用表分片（fragmentation）技术

“表分片”技术允许在表一级对数据存储进行控制。用户可以对表中的记录或索引进行分组，并且存储在不同的位置，这样可以将数据存储到多个磁盘上，从 而减少对磁盘I/O的竞争。数据分片的方案以及分片数据所存放的一组dbspace构成了“分片策略”。数据分片有两种基本类型：轮转法分片 （Round-Robin）和基于表达式分片（Expression-Based），对于“轮转法分片”，数据是根据轮转法方式存入表中的。“基于表达式 分片”则根据表中的一个或多个字段对分片的规则进行定义，一般在预知查询条件时采用这种方式，从而避免查询中对某些分片的扫描。

对表中的数据和索引进行分片主要是为了提高应程序的效率，由于INFORMIX动态服务器可以并行地扫描多个磁盘上的数据，从而实现内部查询的并行 操作，因此采用“分片”技术可以提高查询效率。内部查询的并行化有助于减少对一个复杂查询的响应时间。“表分片”技术与并行数据查询（PDQ）特征联系在 一起使用，这样INFORMIX服务器可以分配多条线索。从所有数据分片上并行地选取数据。此外，还可以仅仅对包含“目标数据”的数据分片进行扫描。从而 大幅度地提高了整个系统效率。

我们通过大量的数据分片将数据分布在许多的磁盘上，也实现了外部查询的并行操作。这样在大量用户对同一个表进行访问时，可以减少I/O的竞争，每秒 钟完成的事务数（系统吞吐能力）也得到了提高。“表分片”技术还通过对存储在dbspace上的数据分片进行备份/恢复操作。

“数据分片”的目标包括最大程度的内部查询并行化、外部查询并行化、提高数据可用性、更细的备份/恢复粒度以及更强的数据加载效率。

使用“表分片”技术的基本原则：

①．对于联机事务处理系统（OLTP），应分片索引，减少会话竞争。

②．对于决策支持系统（DSS），应增加分片表，但不分片索引，分离索引，并把它们放在分离的dbspace中。

③．DSS查询顺序读表，使用轮转法分片（Round-Robin）模式。

④．如果大多请求只存取表中的部分数据，建立基于表达式分片（Expression-Based）。

⑤．保持分片表达式的简单性。

⑥．调整分片表达式，减少测试。如：order_num>=1 AND order_num<=10000 IN dbspace改为order_num<=10000 AND order_num>=1 IN dbspace，效率会更高。

⑦．避免需要数据类型转换的表达式。

⑧．不对改变频繁的字段进行分片。

⑨．不要分片所有表，识别出存取最频繁的关键表。

⑩．不要分片小表。

举例说明两种类型的“表分片”技术使用方法：

（1）、轮转法分片（Round-Robin）

◆建立数据表时指定：

CREATE TABLE my_orders (

order_num SERIAL(1001),

order_date DATE,

ship_instruct CHAR(40),

．．．）

FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3

◆将未作分片的数据表改为分片：

ALTER FRAGMENT ON TABLE my_orders INIT  FRAGMENT

BY  ROUND  ROBIN  IN  dbspace1,dbspace2,dbspace3

（2）、基于表达式分片（Expression-Based）

◆建立数据表时指定：

CREATE TABLE my_orders (

order_num SERIAL(1001),

order_date DATE,

ship_instruct CHAR(40),

．．．）

FRAGMENT BY EXPRESSION

order_num < 10000 IN dbspace1,

order_num>=10000 AND order_num < 20000 IN dbspace2,

REMAINDER IN dbspace3

◆将未作分片的数据表改为分片：

ALTER FRAGMENT ON TABLE my_orders INIT  FRAGMENT

BY EXPRESSION

order_num < 10000 IN dbspace1,

order_num>=10000 AND order_num < 20000 IN dbspace2,

REMAINDER IN dbspace3

4、建表时对表的记录锁方式根据应用处理的不同区别对待。

批量处理的表采用页锁(page)方式，实时交易的表采用行锁（row）方式。锁方式可以在建表时确定，也可以用 alter tabname lock mode(row)和alter tabname lock mode(page)命令改变。值得注意的是通过 dbimport、dbexport转移生成的表其默认锁方式是页级锁，对于实时交易且操作频繁的表应改为行级锁方式，使用oncheck －pt命令可 查得表的锁方式状态。

5、其他一些创建数据库表应遵循的原则

◆ 保证记录的长度较小，最好要小于一个页的大小，跨越多页的长记录对性能无益。

◆ 在绝对有必要的情况下才使用BLOBS，BLOBS比其它数据的处理的效率要低。

◆ 有时为了获得所需的性能，减少连接运算而设计非常规数据模型是必要的，但这是最后的解决办法。

 

 

三、 建立索引的策略

索引是关系数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用ISAM索引结构。在OLTP应用中，事务处 理在很大程度上依赖于索引。如果查询结果仅为一行或很少几行时（高选择性high selectivity），利用索引进行查询会大大提高效率。相比之 下，如果没有索引，查询则只能顺序扫描整个表。只有在表很小时，才会顺序扫描表，顺序扫描表会使系统性能受到严重影响。DSS环境中的应用经常会查询出大 量数据（低选择性 low selecviity），甚至整张表，顺序扫描对于这样的查询更为适合，因为此时顺序扫描可以利用light scan。

1、索引的类型

（1）、分离索引（detached）或基于表达式的索引分片（expression based fragmented）。分离索引和分片索引可 以使得索引的extent内页连续，因而能提高性能。而对于不分片的表来说，附加索引（attached）在建立索引时，索引页和数据页交叉存放在一起， 因而会增加磁头寻找时间。对于中、小型表应该建立分离索引。对于经常访问的大表应考虑建立基于表达式的分片索引，以减少索引页的数量和提高检索速度。索引 分片不宜太多，以免表达式计算开销过大。根据索引的大小，一般可以分为4片。

◆分离式索引与数据页分别存放在不同的数据空间中。例如：

CREATE INDEX index_a ON TABLE table_name(colA) in idxdbs;

◆基于表达式的分片索引在FRAGMENT BY EXPRESSION 子句指定的数据空间中创建。例如：

CREATE INDEX index_a on TABLE table_name(colA)

FRAGMENT BY EXPRESSION

colA>=0 and colA<=20000 in idxdbs1

colA>=20001 and colA<=50000 in idxdbs2；

（2）、隐式索引：在定义约束条件时如果没有可利用的索引，系统将创建隐式索引。用户不能对隐式索引指定数据空间的位置、分片策略或者填充因子。隐式索引创建在数据库（而非表）所在地数据空间中，这给磁盘管理和性能带来了一些影响。

2、建立索引的代价

虽然索引可以很大地提高高选择性查询的性能，但维护这些索引是需要付出代价的。

（1）、存储开销：建立索引将占用许多页的数据空间。

（2）、处理开销：对一个索引表的数据进行编辑时都要同时更新索引。

◆ INSERT语句：在进行插入时系统首先将读取被插入表的索引以定位新记录关键字的位置。然后系统在将新记录写入数据页的同时还必须将新索引项写入索引节点。如果导致索引节点分裂，系统则必须多次写索引页。

◆ DELETE语句：与INSERT类似，DELETE语句也要求读入整个索引以定位索引节点位置，并置上删除标志。在删除索引时还需要处理索引节点合并、整理等问题。

◆ UPDATE语句：执行时必须首先定位并且删除旧的关键字然后插入新的关键字。所以在UPDATE语句必须两次读取索引。

在实际系统中通常把索引的根节点和第一级节点读入共享内存中，但如果需要访问更低层次的索引节点则必须进行磁盘操作。

3、索引策略的优化与原则

（1）、避免高度重复率字段建立索引

高度重复字段的索引会降低性能。如果觉得有必要在包含高度重复值的列上建立索引，最好与包含唯一值（或近似唯一的其它列）建立一个复合索引，服务器仍可以使用该索引来访问重复列值，而该索引得处理效率更高。

（2）、对同一表不要建立过多的索引

太多的索引与不充分、不正确的索引对性能都无益，在表上建立的每个索引都会增加存储开销，索引对于插入、删除、更新操作也会增加处理开支。

（3）、建索引的字段的大小尽量小，复合索引尽量少用。

（4）、复合（compound）索引。

◆ 在一个有唯一值的字段和有重复值的字段上共同建一个复合索引，有助于多重复值的字段的insert操作（增加唯一性）。

◆ 在join相关的多个字段上建复合索引。

◆ 在Where条件相关的多个字段上建复合索引。

（5）、建聚类（cluster）索引，减少索引文件碎片，以加快检索速度。

聚类索引对相对稳定的表较为有用，能加快查询。

◆ 聚类和生聚类都需花费大量磁盘空间和时间

◆ 数据录入时就是有序的，则无需聚类。

（6）、使用FILLFACTOR（填充因子）控制索引页中的空间

填充因子决定了在建立索引时每一索引页的填充度。该参数是可以改变的。参数FILLFACTOR缺省值为90。如果只是改变某个索引的设置，请使用CREATE INDEX的FILLFACTOR子句。例如：下列语句在建立索引时将FILLFACTOR设为70。

CREATE INDEX index_a ON TABLE table_name(colA) in idxdbs FILLFACTOR 70;

设置较大的填充因子可以使索引更紧凑、使缓冲区更有效同时也可以减少检索记录时读取的页数。

◆ 对于只读表可将FILLFACTOR设置为100。

◆ 对于只执行读和删除操作的表，如果将FILLFACTOR设置为100,在删除记录时可以减少合并索引节点、整理索引树的可能性。

◆ 对于有大量插入和更新操作的表，可将FILLFACTOR设置为50到70。由于填充因子较小，在插入和更新操作时将延迟索引节点（页面）的分裂，从而提高系统性能。

（7）、在经常进行连接，但是没有指定为外键的字段上建立索引，而不经常连接的字段则由优化器自动生成索引。

（8）、Where条件子句经常用到的字段上加索引。

（9）、在频繁进行排序或分组（即进行group by或order by操作）的字段上建立索引。

（10）、限制在频繁update的表上建索引的数目。

（11）、对大批量update操作（如load数据）,首先drop index,再update；然后再建索引, 能提高性能。

（12）、数据量小的表是否建索引影响不大，一般不要对记录数小于200的小表建立索引，因为从使用索引得到的速度不能抵消在表上打开和检索索引文件所需的时间。

（13）、用永久索引代替自动索引。

（14）、建primary key。

 

 

四、 查询语句（SELECT）的优化

程序设计中的一个著名定律是20％的代码用去了80％的时间，在数据库应用程序中也同样如此。数据库应用程序的优化通常可分为两个方面：源代码的优化和SQL语句的优化。源代码的优化在时间成本和风险上代价很高；另一方面，源代码的优化对数据库系统性能的提升收效有限。

许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。一个好的查询计划往往可以使程序性 能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询 语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然 后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优 化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。

1、对查询语句进行优化的理由

下列几方面的原因是我们进行SQL语句优化的理由：

◆ SQL语句是对数据库(数据)进行操作的惟一途径；

◆ SQL语句消耗了70%~90%的数据库资源；

◆ SQL语句独立于程序设计逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低；

◆ SQL语句可以有不同的写法；

◆ SQL语句易学，难精通。

从大多数数据库应用系统的实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。

2、查询语句（SELECT）的优化建议

（1）、合理使用索引：where子句中变量顺序应与索引字键顺序相同。

如：create index test_idx on test(bdh, rq, xz)

索 引字键顺序：首先是保单号bdh，其次是日期rq，最后是险种xz，所以where子句变量顺序应是 where bdh<=“P1234”and rq=“06/06/1999”and xz=“DAA”,不应是 where  xz=“DAA” and rq=“06/06/1999” and bdh <=“P1234”这样的不按索引字键顺序写法。

（2）、将最具有限制性的条件放在前面，大值在前，小值在后。

　 　如：where colA<=10000  AND  colA>=1　效率高

where colA>=1  AND  colA<=10000  效率低

（3）、避免采用MATCHES和LIKE通配符匹配查询

通配符匹配查询特别耗费时间。即使在条件字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。

例如语句：SELECT ＊ FROM customer  WHERE zipcode  MATCHES  “524*”

可以考虑将它改为SELECT ＊ FROM customer WHERE  ZipCode<=“524999” AND ZipCode >=“524000”，则在执行查询时就会利用索引来查询，显然会大大提高速度。

（4）、避免非开始的子串

例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3] >“24”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。

（5）、避免相关子查询

一个字段的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的字段值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

例如：将下面的语句

select bdh,bf from TabA

where item IN (select item form TabB where TabB.num=50)

改为：select bdh,bf from TabA, TabB

where TabA.item=TabB.item AND TabB.num=50

（6）、避免或简化排序

应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：

◆ 索引中不包括一个或几个待排序的字段；

◆ group by或order by子句中字段的次序与索引的次序不一样；

◆ 排序的字段来自不同的表。

为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的字段的范围等。

（7）、消除对大型表行数据的顺序存取 

在 嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询 10亿行数据。避免这种情况的主要方法就是对连接的字段进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两 个表要做连接，就要在“学号”这个连接字段上建立索引。

还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：

SELECT ＊ FROM orders WHERE (cust_num=126  AND order_num>1001) OR     order_num=1008

虽然在cust_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：

SELECT ＊ FROM orders WHERE cust_num=126  AND order_num>1001

UNION

SELECT ＊ FROM orders WHERE order_num=1008

这样就能利用索引路径处理查询。

（8）、对于大数据量的求和应避免使用单一的sum命令处理，可采用group by方式与其结合，有时其效率可提高几倍甚至百倍。

（9）、避免会引起磁盘读写的rowid操作。在where子句中或select语句中，用rowid要产生磁盘读写，是一个物理过程，会影响性能。

（10）、使用临时表加速查询

把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。

但要注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。

五、 其他措施

如何优化一套数据库应用程序，除了以上所述的措施外，还有一些分析并提高效率的措施在实际工作中亦应注意使用。

（1）、利用set explain on语句来分析数据库查找策略。

当 发现某一部分INFORMIX语句运行特别慢又找不到原因时，可在程序中的查询语句之前加入“set explain  on”语句，当程序运行时，在程 序运行的当前目录下产生一个“sqexplain.out”文件，记录了INFORMIX数据库服务器采用何种优化策略来查找数据库。在该文件中可以发现 查找中有无使用索引条件，估计的查找代价等信息。

（2）、数据库在做dbimport后应运行update statistics语句。

当数据库系统用dbimport实用程序完成数据库装载后，应运行update  statistics数据库语句保证系统表中统计信息准确，否则将影响数据库优化器的策略和系统运行性能。

例如：select ＊ from test where bdh matches “PC2002＊”

test表在bdh字段上建立了索引，但在数据库运行update statistics前，数据库优化查找策略是按顺序查找而不是按索引查找，严重影响了查找速度。

（3）、经常插入和删除的大表应定期运行update statistics high语句。

　  对经常插入和删除的大表应定期运行update  statistics语句保证系统表中统计信息准确，保证数据库优化器作出正确的优化策略提高系统运行性能。

（4）、对大文件采用load命令装载入库前可先去掉原有的日志方式和去掉索引，等load装载完成后再重建索引和日志，能大幅提高装载效率，避免出错产生。

◆ 去掉原有的日志方式：ontape －S －N dbname

◆ 删除索引：delete index indexname

◆ 用load 装入数据：load from filename insert into tabname

◆ 重建索引：create index to indexname on tabname(colA,colB,……)

◆ 重建日志：ontape －C －B dbname

（5）、针对ESQL/C编程，还应注意程序中的进程的使用

◆INFORMIX数据库中一个事务处理不要跨多个进程。例如：

begin work;

……

if(fork()==0){    /*子进程处理*/

……

conmit work;    /*(或rollback work;)*/

……

}

这种方式，将引起数据库运行效率很低或处理异常。

◆在应用上引入多进程并发处理，充分利用系统资源，能大大提高处理效率。

六、 结束语

应用程序的优化是提高数据库应用系统性能的最佳手段，对应用程序的改善在某些情况下，会给性能带来成倍的提高。而对系统参数的调节不会达到这种地 步。系统性能的不足最终是通过增加系统硬件设备来解决的。此文只是为INFORMIX数据库维护人员和程序设计人员提供一些性能优化的思路和参考，真正的 性能优化还要在具体项目中具体考虑。在性能优化的过程中没有一定之规，这是一个仁者见仁、智者见智的事情。