在线电话营销系统的数据库性能优化

翁英萍

摘要：该文分析了一个在线电话销售系统所遇到的数据库性能瓶颈问题，研究了常见的性能优化策略和方法，针对系统的具体特点选择优化方案，显著地提升了系统性能。

关键词：电话销售；数据库；性能优化

中图分类号：TP311文献标识码：A文章编号：1009-3044(2012)02-0258-02

Performance Optimization in Online Telemarketing System Database

WENG Ying-ping

（College of Computer and Software,Nanjing Insititute of Industry Technology, Nanjing 210046, China）

Abstract:This paper analyses the database performance bottlenecks of an online telemarketing system, researches the popular optimization and tuning strategies,suggests the appropriate optimization scheme according to the features of the system, significantly improves the perfor? mance.

Key words: telemarketing; database; performance optimization

当前，电话营销系统已经将传统的电话营销和数据库营销结合在了一起，使得销售人员可以更加方便的在顾客数据分析的基础上进行有针对性的电话销售，有效提高了扩大顾客群、提高顾客满意度、维护顾客等市场行为的效率。而作为整个电话营销系统关键的数据库系统则显得至关重要。随着销售业务的不断发展，坐席数量、客户数据、通话记录和订单数据的持续增长，数据库系统面临着日益严峻的考验。并发高峰期系统响应时间过长、电话坐席终端反应迟缓甚至停止响应等问题经常发生，严重的影响了整个电话营销系统的正常运行。

销售业务的发展、数据库并发数、数据库数据量三者之间存在线性增长的关系，因此业务的发展意味着数据库系统的维护将经历平稳->逐渐变慢->测试和调优->平稳这样一个反复的循环过程。而“测试和调优”阶段开始的一个有效信号就是数据库系统偶尔出现短暂卡死的现象。

数据库系统调优涉及多个方面，根据优化策略、适应场合的不同，优化代价也不相同。因此需要针对目标系统的具体情况，进行综合考虑。本文首先研究了数据库调优的常见策略，并结合在线电销系统的具体运行情况，选取可行且高性价比的策略进行调优，并随时监控每项策略进行后的性能改善，最终顺利完成当前数据库系统的“测试和调优”阶段。

1数据库调优的常见策略

数据库的性能涉及硬件、网络及应用程序等多个方面。主要包括：

1）系统硬件。系统硬件的性能对数据库的表现至关重要，配置合理的服务器及存储设备能够最有效的提高整个系统的性能。系统性能主要取决于磁盘、内存、CPU和网络。磁盘是最容易被忽略的薄弱环节，快速的磁盘系统可能节省十倍甚至百倍的时间。内存越大，则表的部分或全部保存在内存中的机会也越大，可以大大的减少磁盘I/O的次数，从而极大的提升检索速度。Sql Server2005可以支持多达32个CPU并行工作，选择多个高性能的CPU能提高每个任务的处理速度。网络连接的快慢则决定了数据库服务器与应用服务器之间的数据交换能力。硬件系统的价格比较昂贵，如果单纯采用升级硬件的方式来提升性能，能够得到很好的效果，但付出的代价较高。

2）数据库的设计。数据库设计同样能够极大的影响数据库的性能。数据库设计方面主要考虑如下方面：表的设计、索引的设计和存储过程的使用。数据库表的设计一般应满足三范式，消除冗余，避免插入、删除和修改异常。但适当的非规范化处理可以减少频繁连表和重复计算，和应用程序结合在一起能够很好的降低对数据库查询量的需求。表的设计另一方面需考虑尽可能减少可空列，而采用默认值的方法，减少行的大小。索引的设计在提升查询性能上至关重要，一个有效利用索引的查询可以迅速的定位记录，而不需要全表搜索。有效的使用存储过程，来批量的处理数据可以很好的减少连接数据库的次数。数据库的设计方面的调优一部分可以独立进行，而不影响应用程序和现有系统，没有额外的投资，但是有些部分则需要应用程序做出相应的调整，有些部分则会带来负面影响，比如索引，表的索引越多，增加、删除和修改时的速度越慢。要根据情况均衡考虑。

3）应用程序的设计。主要涉及查询语句的设计方式、锁的类型和持续时间，能不能充分利用索引和存储过程。除此以外还需要平衡业务的需求和整个系统的性能。应用程序的设计准则包括：消除过多的网络流量，使用小结果集；使用存储过程，避免死锁等。

2在线电销系统数据库问题的分析

我们了解到该企业的电销系统数据库的应用程序采用多层架构，有丰富的现场日志，且能够做到直接修改查询语句而不需要重新编译源代码。

首先分析了应用程序保留的卡死那段时间的现场日志。经过对日志的分析发现了如下问题：

1）当时有很多条需要对十多张百万级数据表的联结查询。其中数十条查询时长超过1000ms。对这些查询进一步的分析表明，sql语句中的查询条件不能有效的利用索引，主要原因有如下几点:a.有些字段没有包含在索引之中。b.诸如like‘%xxx%的模糊查询。c.诸如in(x,x,x)的查询。

上述情况由于不能利用索引来查询，导致全表搜索，而全表的数据量非常巨大，因此导致查询时间很长，在并发数很大的情况下会导致系统响应很慢。

2）某个检查工作状态的查询语句每10s检查一次。

3）经常查询的表数据量巨大，最多的通话相关的表达500万条以上，更频繁操作的客户表和订单表也达100万条，还在持续增长之中，很多业务查询都需要这些大表互相连接或聚合统计分析。

其次为了了解当并发量很大,查询集中时，整个系统的瓶颈在哪里，决定选择一个正常的工作周期打开性能监视器，了解性能瓶颈所在。我们选择了正常工作日的一整天24小时。

经过检查发现磁盘I/O存在较大异常，avg.disk.queue.length的平均值都高达60~80，最大值高达700，而合理值是1~3/每块磁盘，当前系统包含2块物理磁盘，那么平均值不应该超过6。因此可以判断磁盘I/O存在异常。

从上述分析可以得出该数据库系统的问题主要有：（1）历史数据过于庞大；（2）表的索引设计存在问题；（3）查询语句设计存在问题；（4）硬件的性能已经无法应付日益庞大的数据量和并发数。

3针对性调优策略的选取

由于该企业的数据库系统是始终运行之中，很多优化措施在应用程序和数据库的设计和开发阶段是比较容易解决的问题，现在却变得不可实现，比如对应用程序的修改，虽然该应用程序可以方便的修改查询语句，但是对于数据的处理方式将很难修改。而且一个表会涉及到多处使用，因此数据库设计方面的缺陷所能做的优化也几乎不可能。因此需要针对数据库系统存在的4类问题进行分析处理。

这4类问题中，其中最容易处理的是（2），因为仅需要对数据库进行操作即可。其次为（3），需要对查询语句进行修改，本来是比较复杂的工作，由于该企业的应用程序是多层架构，查询语句可以方便的修改而不需要重新编译源代码。再然后是（1），历史数据中有很多类型，有些是基本不会被查询的可以移除，有些是核心数据如客户数据和订单数据，这些对公司的业务有着巨大的价值，不可能被转移。对于（4）则更加麻烦，这不仅仅涉及到公司资金的投入，还涉及到如何扩展或更新硬件而不影响现有业务的进行，如何应对扩展或更新过程中所遇到的风险。

因此我们的解决方案是：首先解决（2）、（3），然后是（1）。经过观察后，如有必要再考虑对硬件的升级。具体来说，采用了如下步骤：

1）从日志中选出所有耗时巨大的查询语句，逐一分析，分别处以如下操作：

(1)对于经常需要进行的操作，尽可能去除模糊查询(like和in)。如果业务需要，确实在某些情况下需要模糊查询，则提供2个版本供选择：可以模糊查询和不可以模糊查询的版本。并控制模糊查询的使用

(2)对于所有耗时巨大的且不是因为模糊查询的语句，运用数据库引擎优化顾问来优化，根据建议来重新建立表的索引，确保查询能充分利用索引，减少查询时间

经过步骤（1）的处理后，系统的压力得到了缓解，但是仍然反映很慢。

2）鉴于数据量正在日新月异的增加。沉重的历史数据始终是系统的包袱。因此需要向业务部门提出建议，每种数据确定需要保留的时间。并据此写出清理数据的存储过程，每周进行一次清理，将超过半年、一年以上的数据(根据业务的需求保留时长不等)转移到其他备份数据库中，并在原数据库中清理掉。

经过步骤（2）的处理之后，以及进一步的性能监视之后，发现，磁盘I/O的avg.disk.queue.length的最大值仍然在200以上。虽然对比最初已经有了很好的降低，仍然远远超出建议的值。

3）仔细分析了系统硬件之后发现，当前的数据库文件的大小已达20G，而内存大小仅为4G，显然如果涉及大数据量的查询时，数据库的大部分都在磁盘而非内存中，需要多次磁盘I/O来应对，从而导致磁盘I/O成为瓶颈所在。鉴于这样的原因，建议升级内存到32G。

升级后发现，磁盘I/O迅速的下降为2~4之间。坐席终端也反映系统使用比较流畅。整个系统运行多日未出现卡死现象。至此本次优化取得了很好的效果。

4结论和展望

经过本次数据库系统系统终端的设计会优化，可以发现联机数据库调优涉及很多方面，绝不仅仅是数据库本身的知识。还涉及业务需求、查询语句和应用程序的架构以及硬件的性能。每个方面都对数据库的性能有重大影响。从业务的角度，如何在有限的系统资源中，确保核心业务的进行；如何在业务的便利性和系统资源的消耗之间找到平衡。从应用程序结构的角度，不仅需要考虑实现用户提出的功能，还要预见到在大数据量和高并发情况下，系统性能的影响。如果在设计时就考虑到这一点，就能有更多的优化策略可以采用，比如数据的划分，将同一种数据分在不同表中，从而缩小每个人需要查询的总范围，且减少读写锁的争用。比

如将常见历史数据的查询在业务空闲的夜间进行预查询，并写在临时表中，减少并发高峰时对数据库的查询。比如采用数据仓库来存放不会改变的历史数据，将动态的数据保存在实时库中，大大减少数据库查询的记录数。从硬件的角度来说，如何找到硬件的真正瓶颈，并具有前瞻性的了解业务将来的发展情况，从而估算数据库的大小和需要投入的硬件，避免重复投资。如果能够使用数据库集群，在适当的点添加服务器的数量，从而能够无缝的增加服务器的处理能力，也是将来需要考虑的方向。

参考文献：

[1] Dennis Shasha,Philippe Bonnel.数据库性能调优----原理与技术[M].孟小峰,李战怀,译.北京:电子工业出版社,2004.5.

[2]宋改勤.基于电力负荷管理系统的数据库性能改善[D].郑州:郑州大学,2006.

[3]谷震离.SQL Server数据库应用程序性能优化方法[J].计算机工程与设计,2006,8.

[4]王振辉,吴广茂.SQL查询语句优化研究[J].计算机应用,2005,12.

[5]郭忠南,孟凡荣.关系数据库性能优化研究[J].计算机工程与设计,2006,12.