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

Sybase大量并发查询的优化摘要：在单Sybase服务器条件下，从多个方面对并发查询性能的提升进行了研究，并取得了较好的效果。

关键词：Sybase 并发查询优化1引言一个业务系统，有20台Sybase客户端需要高频度查询转发地址信息。

转发地址信息，每天都有1%~10%的变更。

随着业务数据的逐渐增大，Sybase服务器的CPU和IO也逐渐升高，业务高峰期还可能达到100%，导致查询响应缓慢，转发数据出现积压，实时性下降。

为了提高查询的性能，对Sybase大量并发查询的优化方法进行了多方面的研究。

2设计优化设计优化，主要是直接影响服务器和客户端的设计优化。

2.1 专用索引描述：针对频繁使用的查询操作，设计专用的索引，一般能提高查询性能。

数据量越大，索引发挥的作用约明显。

索引能使查询的时间呈几何指数级的下降。

原来的全表扫描，在有索引条件下，只需要几次比较和寻址就可以定位，输出最终结果。

实施要点：统计业务系统的所有查询指令和使用频度，将使用率高的查询条件的字段作为索引。

索引使用的字段，尽可能是取值比较丰富的，查询结果集在5%以下，索引才能发挥优势。

点评：索引时数据库优化最直接，也是最复杂的方法。

索引应该跟着数据和使用情况及时调整。

2.2 合并索引描述：有时，多个查询操作，每个都创建了专门的索引，以便提高查询性能，但，一个表的索引过多，会导致插入和修改数据性能下降，而且也增加了执行计划解析的时间。

因此，应尽量控制索引的数量。

案例：表（用户user，物品序号oid，信息info）。

由于插入和删除都使用（用户user，物品序号oid）作为条件，因此，这3个字段建了一个索引idx1。

由于查询总是使用（物品序号oid）作为条件，查询返回（用户user，信息info），因此，用这个字段建了一个索引idx2。

其实，idx1已经包含了idx2，但由于字段顺序问题，idx1无法用于查询的优化。

调整idx1的字段顺序，形成idx3（物品序号oid，用户user），可以代替idx1和idx2，完成索引合并。

合并后，查询也能使用idx3。

点评：索引太多，不但占用存储空间，而且对插入操作的性能影响很大，应尽量控制索引的数量。

2.3 使用簇索引描述：如果表的一条记录的数据很小，使用簇索引（C lustered Index），可以减少从索引到数据的寻址过程。

实施要点：创建索引时，使用关键字CLUSTERED ；建聚簇索引需要至少相当该表120%的附加空间，以存放该表的副本和索引中间页点评：一个表的簇索引，至多1个。

簇索引不一定总是比非簇索引性能高。

2.4 合理使用分区技术描述：Syabse高版本已经进入了表分区功能，有利于操控大量数据。

实施要点：根据表的特性，选择适合的字段作为分区字段。

通常使用整数区间，日期作为分区字段。

点评：表分区后，查询指令应尽量在分区内进行。

分区后，没有使用分区字段的查询，还是会全表扫描，应该尽量避免。

3服务器端的优化3.1 一次性申请共享内存描述：Sybase使用的最大共享内存可以通过配置修改，但默认是内存不足时，才再申请新的共享内存。

实施要点：命令：sp_configure "allocate max shared mem",1点评：一次性申请内存，还可以避免因为其他进程占用内存，导致需要内存时申请失败，可以保证Sybase使用内存的总量。

3.2 有名高速Cache绑定到库描述：Sybase默认有一个cache内存，用于保存近期经常使用的数据。

可以给一个库专门开辟cache空间，提高查询性能。

实施要点：1、创建一个200M命名高速缓存db1_cache：sp_cacheconfig ‘db1_cache’,'200m’,'mixed2、将db1_cache绑定到db1：sp_bindcache ‘db1_cache’,db1点评：有名Cache能给库提供额外的缓存空间，能提高经常性、近期重复性的查询性能。

3.3 使用多个独立的存储设备描述：使用多块独立的硬盘，对需要并发读取的表，将存储设备分散到多个磁盘上，可以实现磁盘的并发读写，提高处理性能。

实施要点：在采购时，选择独立硬盘接口数量足够多服务器型号，并配置多块硬盘。

通常一块硬盘安装操作系统和Sybase软件，其他作为设备存储。

点评：采用多块独立硬盘，系统的数据安全性会比RAID 5差些，需要对硬盘的健康状态进行监控，及时更换硬盘。

3.4 使用多个段（Sigment）描述：段（Segment）是数据库设备上磁盘空间的逻辑组合，它可以看作是指向一个或多个数据库设备的标签。

利用段可以控制数据库对象的存放位置，可以将数据库对象分类存放到不同的段上。

设备与段之间的关系：多对多关系。

一个设备上可以创建多个段，一个段也可以覆盖多个设备。

Sybase支持32个段，系统默认有system、default、logsegment 3个段，用户创建对象默认使用default段。

实施要点：创建段：sp_addsegment 段名，数据库名，设备名扩展段的范围：sp_exetendsegment 段名，数据库名，设备名缩小段的范围：sp_dropsegment 段名，数据库名，设备名create table和create index可以使用“on 段名”指定使用的段；在段上放置现有对象：“sp_placeobject 段名，对象名”。

其中，对象名可以使“表名．字段名”，可以实现不同的字段存储在不同的段中。

点评：段能对数据进行分组，分开存储，同时能实现多段数据的并发使用。

3.5 数据与日志存储分离描述：实施要点：点评：3.6 启用OLTP描述：OLTP（Online Transaction Processing），联机事务处理，表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。

实施要点：sp_configure “optimization goal”,”allow_oltp”点评：通过配置，允许Sybase Server在优化时倾向于大量小事务处理的优化，有利于大量并发查询的性能提升。

3.7 定期Rebuild描述：经常进行插入和删除的表，会出现存储碎片，而且数据存储趋于无序状态，即使已经创建了索引，而且数据总量没有增大，也会出现读写性能逐渐下降的情况。

实施要点：Rebuild的指令是：reorg rebuild <table> [index]没有index参数时，对表和该表的所有索引进行rebuild。

Rebuild需要当前存储数据的140%的存储空间，才能正常执行。

点评：定期进行表的rebuild可以使数据有序化，清除碎片，提高查询性能。

如果表比较大，rebuild将比较耗时，不能太频繁。

也不能太久不进行，否则数据还是长期无序化。

通常采用7到30天一次。

3.8 将整个Sybase部署到内存磁盘描述：随着服务器内存的成本逐渐降低，大内存服务器成为可能。

如果数据库系统的数据比较少，可能考虑将整个Sybase软件和存储设备文件都放入内存虚拟硬盘（RamDisk），或者内存文件系统（/dev/shm）中。

这样，可以极大减少磁盘IO 引起的性能瓶颈。

实施要点：操作系统启动时，将磁盘中备份的整个Sybase软件目录和存储设备文件目录，还原到内存，然后直接启动内存中的Sybase Server。

定期备份整个Sybase数据到磁盘，避免突然断电导致的数据丢失。

操作系统关闭时，先关闭Sybase服务，然后备份整个内存中的Sybase软件和存储设备文件到磁盘，以便下次系统启动时还原。

点评：直接将数据库系统和数据都放入内存，可以大大简化数据库有关IO方面的配置，因为基本上可以不配置高速Cache等表级的内存使用策略。

同时，定期备份机制同时提高了系统容灾能力，还能提供了多个数据还原点。

4客户端的优化4.1 客户端使用长连接描述：连接数据库的过程，比较复杂，而且连接释放，也需要一段时间。

保持数据库连接，可以避免连接和释放的资源动态创建和回收过程。

实施要点：数据库客户端采用单进程、查询代理、数据库连接池等技术实现数据库连接的保持。

点评：在大量频繁的查询业务中，应避免每次查询都进行数据库的连接过程。

4.2 查询语句的优化描述：查询指令的优化，是一个很大的课题，这里，对我负责的项目遇到的实际情况，说明一种优化方法案例：使用联合（union）代替“或”（or）条件。

例如：select name from obj whare id=123 or id=987可以优化为：Select name form obj where id=123UnionSelect name from obj where id=987点评：查询语句的优化是一个复杂过程，需要积累大量的实战经验。

同时，还应从设计层面，也就是根本的层面对表结构进行优化。

4.3 绑定变量描述：使用绑定变量，可以减少服务器端对SQL的语法、语义、执行计划的计算时间，有效提高经常使用的SQL执行的执行效率。

实施要点：客户端代码，使用PreparedStatement相关的系列函数调用，实现绑定变量方式的数据库操作。

如果操作中存在数据库对象变量，则无法使用绑定变量。

点评：如果操作频繁，而且SQL语句形式相对固定，应尽量使用绑定变量。

并将该要求写入公司的编码规范。

5结论和展望通过对了解Sybase的内部实现方式的深入理解，在业务系统上逐渐形成了优化方案，通过测试和实际应用，系统的性能得到极大的提升。

以上是一些提升大量并发查询的优化措施的列举，在项目的实际设计、应用中，应该根据业务系统的数据情况、使用情况，选择适当的措施进行性能优化。

各种措施，都存在自身的局限性，应进行全面的衡量，选择性能的最佳平衡点。

Sybase作为一个跨平台、高稳定性、高可伸缩性、高复制性能的数据库系统，依然在银行、政府系统担当这重要的角色。

【参考文献】《性能和调优系列：物理层面的数据库调优》2009年3月Sybase《性能和调优系列：查询处理和抽象计划》2008年11月Sybase。