SQL Server 性能优化中的几个见解

最近领导Boris让我整理一些文档，总结一下我之前做过的性能优化项目中的一些想法和流程，形成一个性能优化服务项目介绍。这里顺手把这些东西摘取一些，放到这篇文章里面，这篇文章里面不讲技术，因为如果写技术的话，可以写一本500P的书，这里只和各位分享一下我在性能优化项目中的几个见解，谈不上经验。
一、影响系统的因素：[/b][/b]
系统性能的好与坏，是多方面导致的。就好像我们的身体，一个部位不适，会导致人感觉不爽，即便我们足够强壮。不少的企业都在这方面遇到了问题——当性能出现问题之后，更换了很强健的服务器，但是还是感觉性能很差。这也像一个富贵的家庭，有了一个败家子的儿子，金山银山也掏空，即所谓富不过三代。生活中的道理，部分在计算机系统中还是通用的，毕竟计算机也是人设计出来的。
在一些企业形成了这样的困局：
l 软件开发商说：我们开发的软件没有问题，在其他客户那里也是跑得顺顺当当的
l 采购说：又要换服务器啊，上次硬件采购才过了多久啊，今年经济不景气啊！
l 用户说：这套系统已经严重影响我们的工作效率
l 领导说：这个问题已经拖了很久，已经很严重了，必须尽快解决
l ……




在做性能优化项目之前必须找到系统的瓶颈在哪里，定位了问题所在才能解决问题。上面这幅图中列出了影响系统性能的一些因素。
在我多年与SQL Server 打交道的经历中，导致系统性能低下最主要的原因是：
l 应用逻辑设计不合理
l 查询写得不好
l 表设计不合理
l 索引设计不合理
在做

二、二、性能优化的流程：[/b][/b]
性能低下是一种慢性病，比较广泛发生在SQL Server 服务器群中，不具备传染性，没有可能自愈，通常病情会愈加严重。建议早发现早治疗，一般服药两个疗程可以治愈，痊愈后定期检查，平时注意控制……



呵呵，开个玩笑。
性能优化项目大概类似如此，经过收集→分析→设计→实施，最终解决问题。
1. [/b]收集阶段[/b][/b]
使用性能监视器、SQL Server Profiler和一些脚本等，收集性能数据。收集至少24小时甚至更长的时间，可以在月结，报表日等业务高峰时间段额外收集。收集期间会有少许的性能影响。
这里要说一下的是，Profiler也就是事件探查器是一个非常强大的收集工具，除了收集T-SQL的执行情况之外，还可以收集死锁和阻塞等。收集到的结果，可以导入性能监视器的数据，组合起来分析，观察在某个参数在峰值的时候数据库干什么。



2. [/b]分析问题[/b][/b]
从收集的性能数据中进行分析，例如：
l 用户在什么时间或者做某个操作的时候，会觉得慢
l 硬件中哪个组件是性能瓶颈
l 哪些表数据过多
l 哪些索引的碎片很严重
l 哪些数据库或者服务器的配置不合理
l 哪些查询最慢而且执行次数最多，返回的记录数非常多，磁盘的读写非常大
l 发生了哪些阻塞和死锁
l ……
我们可以将数据整理成看起来一目了然的Excel表格，例如下面这张分析查询的执行时间和次数的表格，可以让我们找到需要优先解决的问题：执行次数很多，平均执行时间很长的语句。



3. [/b]设计优化方案[/b][/b]
在分析了问题之后，我们需要设计优化方案。有些优化方案对应用和业务没有影响，有些数据库的优化方案可能影响到应用程序，需要开发人员配合。调整的方案可能是：
l 调整表的设计：归档数据，分区，添加冗余键等
l 索引的调整：去掉不合理的索引，创建必要的索引，创建自动的索引维护计划
l 调整配置：调整数据库和操作系统的配置
l 调整应用程序：调整不合理的查询，不合理的业务逻辑设计，访问数据的方式，控制访问数据量等等
l ……
各种优化方法和性能影响因素相关性如下：



设计出来的实施方案，需要经过测试和论证。以确认这种修改是否有效，和减少调整所带来的负面影响。
4. [/b]实施[/b][/b]
在系统空闲时间，将调整索引、应用程序、数据库设计等方面的优化方案实施到生产系统上。并记录下来，最后形成一个实施报告。
我不认为一次性能解决所有的问题，通常要需要经过两个疗程之后，才能有所好转。以后间隔一个时间进行一次检查，解决我们遗漏的一些问题。

三、三、[/b]DBA 该做些什么？[/b]

在一次管理专家课程开始之前，我让每位同学谈一谈各自对这个角色的看法，主要从两个方面：一是数据库的管理最重要的是什么，二是DBA平时主要的工作是什么？ 对于第一点，数据库管理中最重要的是什么？所有的同学的看法几乎一致，可以概括为三个字——稳定性。详细一点就是：数据不要丢失，数据库服务器不能宕机。基本也是如此，只是再加上“安全性”，因为数据安全不只是数据不会损坏，还有信息的机密性。
对于第二点，DBA平时主要的工作是什么？很多同学的看法不同，有人说是管理数据，有人说设计数据库，有人说备份和恢复，有人说建立群集等等高可用性方案，还有人说是做数据的ETL。我的看法有些不同。
设计数据库是谁做的？通常是数据库开发人员或者软件供应商做的；数据管理太过初级，增删改查，这样的数据操作由应用程序来实现了；备份和恢复、数据的ETL只要做一次，设计好作业以后由数据库定期调度就可以了；群集、数据库镜像等也只要做一次就可以了。上面的这些管理任务，DBA必须掌握，掌握了之后，做成自动化的管理计划，就可以让自己解放出来了。



[align=center] [/align]

DBA 需要定期检查服务器的日志，发现有错误日志，就进行排错；定期检查数据库文件的空间，发现空间不够了，手工扩展一下空间；定期检查一下备份、ETL、索引维护、报表处理、数据归档、复制等自动调度作业是否运行正常等之外，还有一项最重要的工作，就是监视和调整数据库服务器的性能。
要不然同学们去找工作的时候，就得先问问对方，贵公司系统有没有性能问题，如果有的话那我就不去了，因为我也做不了。
性能问题虽然不是每个企业都会遇到，但是遇到了是让人非常头痛的。一个合格的DBA来说，至少要具有能发现性能问题和找到解决途径的能力。
啰啰嗦嗦，也有两千字了。好了，到这里了，就到这里了。
本文出自 “imdbt” 博客，转载请与作者联系！