Sybase大量并发查询的综合优化.doc

Sybase大量并发查询的优化 摘要： 在单Sybase服务器条件下，从多个方面对并发查询性能的提升进行了研究，并取得了较好的效果。 关键词：Sybase 并发查询 优化 引言 一个业务系统，有20台Sybase客户端需要高频度查询转发地址信息。转发地址信息，每天都有1%~10%的变更。随着业务数据的逐渐增大，Sybase服务器的CPU和IO也逐渐升高，业务高峰期还可能达到100%，导致查询响应缓慢，转发数据出现积压，实时性下降。 为了提高查询的性能，对Sybase大量并发查询的优化方法进行了多方面的研究。 设计优化 设计优化，主要是直接影响服务器和客户端的设计优化。 专用索引 描述： 针对频繁使用的查询操作，设计专用的索引，一般能提高查询性能。 数据量越大，索引发挥的作用约明显。索引能使查询的时间呈几何指数级的下降。原来的全表扫描，在有索引条件下，只需要几次比较和寻址就可以定位，输出最终结果。 实施要点： 统计业务系统的所有查询指令和使用频度，将使用率高的查询条件的字段作为索引。 索引使用的字段，尽可能是取值比较丰富的，查询结果集在5%以下，索引才能发挥优势。 点评： 索引时数据库优化最直接，也是最复杂的方法。索引应该跟着数据和使用情况及时调整。 合并索引 描述： 有时，多个查询操作，每个都创建了专门的索引，以便提高查询性能，但，一个表的索引过多，会导致插入和修改数据性能下降，而且也增加了执行计划解析的时间。因此，应尽量控制索引的数量。 案例： 表（用户user，物品序号oid，信息info）。 由于插入和删除都使用（用户user，物品序号oid）作为条件，因此，这3个字段建了一个索引idx1。 由于查询总是使用（物品序号oid）作为条件，查询返回（用户user，信息info），因此，用这个字段建了一个索引idx2。 其实，idx1已经包含了idx2，但由于字段顺序问题，idx1无法用于查询的优化。调整idx1的字段顺序，形成idx3（物品序号oid，用户user），可以代替idx1和idx2，完成索引合并。合并后，查询也能使用idx3。 点评： 索引太多，不但占用存储空间，而且对插入操作的性能影响很大，应尽量控制索引的数量。 使用簇索引 描述： 如果表的一条记录的数据很小，使用簇索引（Clustered Index），可以减少从索引到数据的寻址过程。 实施要点： 创建索引时，使用关键字CLUSTERED?； 建聚簇索引需要至少相当该表120%的附加空间，以存放该表的副本和索引中间页 点评： 一个表的簇索引，至多1个。簇索引不一定总是比非簇索引性能高。 合理使用分区技术 描述： Syabse高版本已经进入了表分区功能，有利于操控大量数据。 实施要点： 根据表的特性，选择适合的字段作为分区字段。通常使用整数区间，日期作为分区字段。 点评： 表分区后，查询指令应尽量在分区内进行。分区后，没有使用分区字段的查询，还是会全表扫描，应该尽量避免。 服务器端的优化 一次性申请共享内存 描述： Sybase使用的最大共享内存可以通过配置修改，但默认是内存不足时，才再申请新的共享内存。 实施要点： 命令： sp_configure allocate max shared mem,1 点评： 一次性申请内存，还可以避免因为其他进程占用内存，导致需要内存时申请失败，可以保证Sybase使用内存的总量。 有名高速Cache绑定到库 描述： Sybase默认有一个cache内存，用于保存近期经常使用的数据。可以给一个库专门开辟cache空间，提高查询性能。 实施要点： 1、创建一个200M命名高速缓存db1_cache： sp_cacheconfig ‘db1_cache’,200m’,mixed 2、将db1_cache绑定到db1： sp_bindcache ‘db1_cache’,db1 点评： 有名Cache能给库提供额外的缓存空间，能提高经常性、近期重复性的查询性能。 使用多个独立的存储设备 描述： 使用多块独立的硬盘，对需要并发读取的表，将存储设备分散到多个磁盘上，可以实现磁盘的并发读写，提高处理性能。 实施要点： 在采购时，选择独立硬盘接口数量足够多服务器型号，并配置多块硬盘。通常一块硬盘安装操作系统和Sybase软件，其他作为设备存储。 点评： 采用多块独立硬盘，系统的数据安全性会比RAID 5差些，需要对硬盘的健康状态进行监控，及时更换硬盘。 使用多个段（Sigment） 描述： 段（Segment）是数据库设备上磁盘空间的逻辑组合，它可以看作是指向一个或多个数据库设备的标签。利用段可以控制数据库对象的存放位置，可以将数据库对象分类存放到不同的段上。 设备与段之间的关系：多对多关系。一个设备上可以创建多个段，一个段也可以覆盖多