探讨电话销售系统的特性

前言：本站为你精心整理了探讨电话销售系统的特性范文，希望能为你的创作提供参考价值，我们的客服老师可以帮助你提供个性化的参考范文，欢迎咨询。

数据库调优的常见策略数据库的性能涉及硬件、网络及应用程序等多个方面。主要包括：1）系统硬件。系统硬件的性能对数据库的表现至关重要，配置合理的服务器及存储设备能够最有效的提高整个系统的性能。系统性能主要取决于磁盘、内存、CPU和网络。磁盘是最容易被忽略的薄弱环节，快速的磁盘系统可能节省十倍甚至百倍的时间。内存越大，则表的部分或全部保存在内存中的机会也越大，可以大大的减少磁盘I/O的次数，从而极大的提升检索速度。SqlServer2005可以支持多达32个CPU并行工作，选择多个高性能的CPU能提高每个任务的处理速度。网络连接的快慢则决定了数据库服务器与应用服务器之间的数据交换能力。硬件系统的价格比较昂贵，如果单纯采用升级硬件的方式来提升性能，能够得到很好的效果，但付出的代价较高。2）数据库的设计。数据库设计同样能够极大的影响数据库的性能。数据库设计方面主要考虑如下方面：表的设计、索引的设计和存储过程的使用。数据库表的设计一般应满足三范式，消除冗余，避免插入、删除和修改异常。但适当的非规范化处理可以减少频繁连表和重复计算，和应用程序结合在一起能够很好的降低对数据库查询量的需求。表的设计另一方面需考虑尽可能减少可空列，而采用默认值的方法，减少行的大小。索引的设计在提升查询性能上至关重要，一个有效利用索引的查询可以迅速的定位记录，而不需要全表搜索。有效的使用存储过程，来批量的处理数据可以很好的减少连接数据库的次数。数据库的设计方面的调优一部分可以独立进行，而不影响应用程序和现有系统，没有额外的投资，但是有些部分则需要应用程序做出相应的调整，有些部分则会带来负面影响，比如索引，表的索引越多，增加、删除和修改时的速度越慢。要根据情况均衡考虑。3）应用程序的设计。主要涉及查询语句的设计方式、锁的类型和持续时间，能不能充分利用索引和存储过程。除此以外还需要平衡业务的需求和整个系统的性能。应用程序的设计准则包括：消除过多的网络流量，使用小结果集；使用存储过程，避免死锁等。

在线电销系统数据库问题的分析我们了解到该企业的电销系统数据库的应用程序采用多层架构，有丰富的现场日志，且能够做到直接修改查询语句而不需要重新编译源代码。首先分析了应用程序保留的卡死那段时间的现场日志。经过对日志的分析发现了如下问题：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）硬件的性能已经无法应付日益庞大的数据量和并发数。

针对性调优策略的选取由于该企业的数据库系统是始终运行之中，很多优化措施在应用程序和数据库的设计和开发阶段是比较容易解决的问题，现在却变得不可实现，比如对应用程序的修改，虽然该应用程序可以方便的修改查询语句，但是对于数据的处理方式将很难修改。而且一个表会涉及到多处使用，因此数据库设计方面的缺陷所能做的优化也几乎不可能。因此需要针对数据库系统存在的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之间。坐席终端也反映系统使用比较流畅。整个系统运行多日未出现卡死现象。至此本次优化取得了很好的效果。

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

作者：翁英萍单位：南京工业职业技术学院计算机与软件学院