记得以前在学习数据库知识的时候，特别喜欢看案例，因为优化的手段容易掌握，但是整体的优化思路很难学.这也是我特别喜欢看案例的原因，今天也分享一下自己的优化案例。之前分享过OA系统和HIS系统，今天我们就来谈谈最常见的ERP。ERP系统应用于各行各业，不同的行业有不同的特点。博主在做研发的时候自己写过ERP，所以比较熟悉。不管是本文分享的零售品类，还是鞋服、家居、汽车、房产等，也无论是某朋友、某菜，ERP都有一个共同的特点，单据流程时间长、业务复杂、热点表明显、数据量大、涉及系统接口多、各种大数据的统计报表……传统行业缺乏DBA细心管理。慢是常态！最近很忙，博客的产出少得可怜。今天把做了优化或者各种解决方案的客户整理了一下。现有客户千余人，涉及各行各业。今天分享的案例就是这些客户中比较典型的，高大上没有通病。在之前的博客中已经提到过，那么本文我们就结合之前的技术要点来看一下这个案例。用户现象系统慢！非常慢！保存文档需要几分钟时间，很多操作都会超时，尤其是下午4:00左右。当出现各种超时，收不到款的时候。报表查了一个小时，下班还没查完，经常因为系统慢加班，被业务部门投诉。这件事已经上报公司高层，IT压力很大！系统环境首先我们来看一下系统配置和现状。为什么说这个客户是经典呢？往下看就知道了...先来看看系统配置：服务器配置有：8路24核带超线程，384个逻辑CPU，1T内存，全闪存盘：SQL使用2012版本，补丁是最新的，可以识别所有服务器配置。这是正确的。相当棒的配置！数据库大小为1.2T。乍一看，你可能会认为数据量太大会导致性能问题，但转念一想这么强大的服务器不会这么慢吧？是不是代码有问题？分库分表有必要吗？数据库指标那我们来看看数据库的一些表象：每秒请求数：用户连接数：语句执行：等待情况：等待时间：CPU指标：内存的一些指标磁盘队列：----------------很多指标就不一一展示了--------------看到这些基本指标，除了慢还能看到什么？哪里有问题？如何快速解决？有没有优化的步骤摆在我们面前？分析系统真的很慢。慢语句多，系统阻塞严重。这确实与客户报告的缓慢一致。那么为什么这么慢呢？是什么原因造成的？我总结一般性能慢往往和6大因素有关：业务压力硬件环境代码数据库内部运行因素架构这里画个草图：系统压力：访问压力（又称并发））其实并不大，数量用户连接数没有想象的那么多；硬件：内存和磁盘IO确实有压力；环境：服务器和数据库版本没有问题，具体配置稍后再看；code：代码我不想分析了，留到最后；数据库内部运行因素：从各项指标分析，系统语句等待时间过长，导致语句完成缓慢，等待主要有两部分：硬件资源实在不足压力;语句前阻塞太严重，“LCK_M_”，等待时间太长，平均达到数百秒。重新分析……这么强的硬件，访问压力不大，居然造成了瓶颈？陈述文笔不好？方案实施不力？缺乏指标？环境配置错误？让我们来看看....优化阶段一（例行优化）很多时候系统慢，找出原因。上线的时候这么慢吗？那不可能，厂家根本发货不了！那么问题来了，系统什么时候开始变慢的？系统做了哪些调整？简单的研究，攻击！我靠！！！厂家完全不合作，工程师对系统也极不熟悉。厂商给出的结论：继续加硬件，更强的IO，数据分离减少数据量……协调厂商完全协调不了，基本没用。既然是数据库问题，那我们就从数据库入手吧！从数据库从业者的角度来看，看到这样的系统首先要解决大区等待的问题。根据个人经验，很多系统都在等待大面积的解决，系统会有很大的改进和完善。使用一些传统的调整方法，第一阶段开始。主要是针对大面积的系统创建影响大、成本高的索引，调整系统参数，优化tempDB等，我就不细说了，在之前的系列文章中都有。预期：一般来说，上一轮的系统优化会有明显的提升。我觉得这一轮下来系统会明显变快，语句运行环境合适，索引合理的资源消耗自然会少一些，内存和IO压力也会降低。.结果：系统内存和IO压力趋于稳定，慢语句减少了，但是还是很多，阻塞依然存在，超过2分钟的语句还是很多。优化前：优化后，优化前，优化阶段2（针对语句）后，再次分析解决大面积语句阻塞的系统，发现目前的情况主要是：内存有时还是有波动的，但整体IO内存已减少。不是瓶颈。系统中SLEEPING的程序阻塞时间长，部分函数语句仍然很慢，消耗资源较多。再调查系统：慢语句执行的是什么业务？是业务功能吗？还是报告？还是接口？系统中频繁且缓慢的语句。什么是系统中的阻塞操作。经过研究，我遇到了最常见也是最大的问题：由于程序导致的语句慢。在HIS的优化案例中，是因为程序使用了大量的自定义函数，我们改不了，就巧妙的绕过了。那么这次我们如何绕过它呢？一：在报表分析中，发现报表是程序系统中消耗资源最多的。报表通过一系列复杂的查询插入到物理临时表中。什么是物理临时表？它不是#temp，而是实际插入到表中。用完了就删除！插入删除，和中间的业务表有关联操作，报表也会阻塞业务！插入和删除的数据量是多少？猜一下？几千万....二：频繁调用接口程序中的业务数据并发更新频繁，导致业务中断。三：问题代码代码主要有两个问题：代码比较复杂，需要细心优化。程序中存在连接泄漏，简单理解为程序报错后无法有效处理事务，导致事务无法提交阻塞系统。对于报告的第一部分，表述极为复杂。这个东西短时间内优化不了，考虑拆分出来；第二部分界面，修改界面视图，包括文字优化，增加索引，调用频率等；针对第三部分业务对语句、查询提示、计划向导、重新编译等进行详细优化优化阶段3（报表分离）经过前两个阶段的优化，系统一般会有明显的提升，只留下有的报表未被处理，以及一些高消耗的频繁接口查询。我们使用报表分离来解决这部分。这里我们遇到一个问题，报表需要写物理表。用2012自带的AlwaysOn是没办法实现的（从节点只能读）。采用发布订阅方式不能同时满足数据安全和业务连续性的要求，客户不满意。我们想能不能把写物理表改成#temp临时表？软件厂商给出的结论是：不可能。。。那我们就用第三方产品Moebius集群（这里真的不是打广告。。。）如何实现：多活集群，几个节点数据一致实时，这样的基础知识并不流行……也避免了集群介绍；首先，程序只有一个连接字符串，无法将报表指向辅助服务器，我们只能通过Moebius集群的前端调度引擎自定义规则，将报表中使用的存储过程指向第二台服务器，解决了程序无法分离的问题。其次，Moebius集群可以使两个节点都可写，以满足辅助节点报表查询写入物理表的需要。再次，临时表的写入量太大，千万级数据的同步也是个问题。这里的好处是程序中写的物理临时表都是以“Temp_”开头，以GUID类型结尾。我们这里设置只要这样的写表就不会反向同步到master节点，这样按照规则控制双向同步，满足上报的要求，最终实现上报的分离.报告快吗？当然不是，只是分离不能快，但是有三个好处：OLAP和OLTP分离解决了事务阻塞；报表服务器和业务服务器可根据自身业务单独个性化；根据报告的要求我们配置高速IO硬件。期望：语句已经优化，阻塞情况已经解决，CPU、内存、磁盘压力都没有了，系统一定快起来了！结果：系统很快就起来了！最后是业务系统节点一天24小时的慢语句数：（虽然也有慢语句，毕竟是TB级别的数据量，在不影响业务运行的情况下，客户是完全可以接受的。）总结系统慢，我们往往需要综合分析。本文提供的维度：业务压力、硬件环境、代码、数据库、内部运行因素、架构往往是优化的。真不是一个语句的简单调整，再加上一个硬件，综合分析才是从根本上解决性能问题的首要任务。当然，并不是所有的优化都能完全解决。比如本文对报告的改进，就是通过读写分离实现的。在ERP系统中处理报告通常就是这种情况。如果仔细优化报告，需要多长时间？！也许这一切都被重写了。本文优化过程主要为：系统问题综合分析→宏观层面解决方案（环境、数据库内部运行因素、硬件压力）→低效代码调整→架构方案实施（稳定、安全、高效）→最终系统流畅无压力。当然，这个案例中客户的数据量已经到了可以做数据分离、分区、分表的阶段，但是分享这个案例的原因是，不要认为TB级的数据一定要分库分表.您仍然可以从简单的性能调整工作中获得更大的好处。真心希望各位评委在选择分库分表的巨大代价之前，能够找专业人士进行综合分析，仔细评估一下你们系统的瓶颈是什么。！
