作者介绍吴宇，SQL专家云团队成员，擅长解决SQLSERVER数据库性能、高可用、负载等问题平衡。记得我在学习数据库知识的时候，特别喜欢看案例，因为优化的手段容易掌握，但是整体的优化思路很难学，所以特别喜欢看案例。今天整理了我做过的100多个优化或者各种解决方案的客户案例。本文分享的案例就是这些客户中的典型案例！没什么大不了的，都是老生常谈！废话不多说，直接开始！系统环境首先我们来看一下系统配置和现状。这个客户为什么经典？那是因为这个客户已经到了可以慢的地步，不该慢的地方也慢了！首先，这是一套医院的HIS系统有多慢？各种功能都卡住了，不管是支付，医嘱，还是处方。几乎所有功能都很慢。但是卡慢的现象只在早高峰出现！先看一下系统配置：数据库版本为SQLSERVER2008R2，数据量1T左右，服务器64CPU，128G内存，服务器只运行数据库。乍一看，服务器确实有点旧，数据量也很大，内存和CPU明显不够用！数据库指标我们来看看数据库的一些表象：每秒请求数：语句执行状态：等待状态：等待时间：CPU指标：内存一些指标：磁盘队列：还有很多指标就不一一展示了一个。看到这些基本指标，除了慢还能看到什么？哪里有问题？如何快速解决？能不能有个优化步骤摆在你面前？优化阶段1（常规优化）经常系统慢原因，上线就这么慢吗？那不可能，厂家根本发货不了！那么问题来了，什么时候开始变慢了？在研究的时间里，了解到的基本问题是系统在上个月增加了很多功能，还推出了很多其他的系统接口！然后只是创建新的功能和新的程序接口语句？我认为情况并非如此。从数据库从业人员来说，看到这样的系统，首先要解决大区等待的问题！从个人经验来看，很多系统都有一大片区域等待系统解决。会有很大的提升和提升！一些常规的调优方法，阶段开始，主要是创建对系统影响大、成本高的大规模索引，调整系统参数，优化tempDB，开启快照读取等。预期：上一轮优化一般系统会有明显的提升。我觉得这一轮之后的系统会明显变快，语句CPU会下降到70%左右，内存压力也会降低。结果：信心满满，第二天去了各个部门...有些功能还是超时或者慢...CPU还是在90%以上，内存压力还是很明显。不过根据收集到的数据来看，长期语句的数量已经大大减少，等待阻塞的系统也有明显的改善。优化前和优化后第二阶段优化和优化后（针对语句）重新分析了解决大规模语句阻塞的系统，发现目前的情况主要有以下几种：内存不足导致的IO压力.系统CPU仍然很高。一些函数语句仍然很慢并且消耗大量资源。再次调查系统：哪些功能很慢，执行了哪些语句。系统界面语句问题。系统中有没有消耗高资源的语句，是否可以优化？研究了一下，遇到了最常见也是最常见的问题：因为程序导致语句慢！很多人看到这个会说程序慢，改一下，那是什么问题呢？问题是你直接做优化，开发人员说你的程序太烂，必须改！如果您是程序开发人员，您的反应是什么？他会说：对不起，影响太大，无法改变！那么这个优化项目就黄了，或者你要付出更多的代价来绕过这类问题。分析过程中发现该程序大量使用了各种自定义函数。有一定经验的人应该都知道，对于过滤后的列上使用函数的语句，是没有办法使用索引查找的，所以和这个单表数据相比，就是几百甚至上千万的表，简直是灾难！但如果不能贸然修改程序，又如何优化呢？经过粗略的分析，得出该程序主要消耗在几个部分：部分业务功能语句比较慢。接口语句慢（主要是视图，供其他程序调用）。还有一个报告程序。第一部分，如果程序无法更改，尝试添加计划向导来更改语句的执行；第二部分，修改界面视图，包括更换功能，增加索引等；报告的第三部分，这个东西短期内没有优化，所以在原来的镜像方案中加入快照，实现了简单的读写分离，可以直接分离；语句优化的效果：优化前，优化后，优化前，优化后：90%的高消耗语句都得到了优化后，系统应该可以起得更快，CPU和内存指标应该是普通的！结果：语句的消耗和时间都减少了，系统的慢有明显改善，但是CPU还是在90%以上，内存压力还是比较明显。磁盘队列仍然很高！系统性能问题仍然存在。第三阶段优化（深度索引分析）经过前两阶段优化后，系统一般会有明显改善，指标正常。这也是上面说的慢，慢已经解决了。那为什么CPU和内存压力没有缓解呢？是真的吗？问题是不能支持64CPU和128G内存？需要加内存来代替CPU？有必要做负载均衡吗？很大一部分不应该被语句执行消耗掉！那么服务器上没有其他程序在运行，CPU资源哪来的？看这个计数器：SQL编译次数峰值达到每秒2000多次！很多书上都有写，相信很多读者也知道语句不参数化会对CPU造成压力。这是一个生动的例子！该解决方案也比较粗糙。如果无法修改程序，则在数据库上启用强制参数化。看效果：我觉得没啥好说的！内存分析看到了CPU的现象，那么内存的问题也很明显。编译了这么多ad-hoc查询，先看看内存中缓存的数据：SQLOPTIMIZERSinglepage占了80多G，而查询数据页的缓存只有20G，而且还在不断压缩，所以奇怪的是内存没有压力！这个SQLOPTIMIZERSinglepage试了之后通过DBCCFREExxxxx的运行无法释放，所以半夜直接重启了SQL服务！将近2年没有重启的SQL服务到我手上了！重启后出现pagelifecycle:memory问题，不知道是不是微软的小bug，查询计划的缓存个人不太懂。数据缓存已经被挤爆了，客户的数据库也没有打补丁，但是查了08的各种补丁也没有找到相关问题的修复方法，还请见过或者了解的朋友指点一下！期望：语句已经优化，阻塞情况已经解决，CPU、内存、磁盘压力都没有了，系统一定快起来了！结果：系统很快就起来了！总结文章我只是简单描述了某医院HIS系统的优化过程。当然，整个过程的细节一定不能在一周的工作中仅仅写一篇文章就讲得那么详细。希望官方见谅！整个优化过程就是程序只修改了2条语句，其他都是通过数据库优化的方式完成的。并且没有添加任何硬件资源！（文中使用的工具链接：http://www.grqsh.com/product_Expert.html）优化过程主要分为：整体系统调研：与部门用户沟通缓慢，系统近期变动，收集数据。总体优化：调整数据库参数配置，增加索引，解决阻塞。再排查：系统函数慢，语句慢。对于句子优化：写的不够，是否有遗漏的索引，是否可以添加提示，计划向导等整体压力是否缓解：如果压力还是很大，找到瓶颈，是否可以解决？如果不能解决，可以考虑增加硬件或者选择分离、分离等解决方案。
