sqlserver性能调优经验总结

相信不少的朋友，无论是做开发、架构的，还是DBA等，都经常听说“调优”这个词。说起“调优”，可能会让很多技术人员心头激情澎湃，也可能会让很多人感觉苦恼。当然，也有很多人对此不屑一顾，因为并不是每个人接触到的项目都很大，也不是每个人做的项目都对性能要求很高。

在主流的企业级开发和互联网应用中，数据库的重要性是不言而喻的，而数据库的性能对于整个系统的性能而言也是至关重要的，这里无庸赘述。

sqlserver的性能调优，其实是个很宽广的话题。坦白讲，想从概念到实践的完全讲清楚并掌握透彻，可能至少需要几本书的内容。本文只是一个概念级的总结，希望读者能对此有新的认识，在调优路上有所帮助。如果感兴趣的朋友很多，后续可能会分享一些实战经验。

首先搞清楚，性能调优的目标

从最直观，最常见的角度来讲，主要包含如下两点：

优化响应时间

何为“优化响应时间” 呢？说的通俗点，就是经过调优后，执行查询、更新等操作的时候，数据库的反应速度更快，花费的时间更少。

比较常见的，以前执行某条sql查询语句，可能需要3秒钟，加了索引后，1秒钟不到就搞定了。加索引，这也是最典型最"廉价"的优化手段。

在做“优化响应时间”时，需要了解：用户环境，程序，环境，用户和数据等方面的知识。

优化吞吐量

说起“吞吐量”，那就要想到“并发”了。其实就是“同时处理请求”的能力。如何提高数据库"抗并发"的能力呢？首先要了解sqlserver是如何访问数据的，如何控制并发访问的(事务隔离级别，锁等)，如何与底层操作系统进行交互的，还要了解“多线程、进程”等方面的知识。

比较常见的手段，通过降低事务隔离级别（一定程度地牺牲数据一致性等），这种“软手段”通常会起到很好的效果。其次，单台DB Server达到一定瓶颈后，可以通过“集群”等方式，实现请求的“负载均衡”的，来达到“抗并发”的目的，效果也是立竿见影的。

性能调优的方法论--迭代

基线

通俗点讲，就是用来计算或者比较的标准。通常以当前系统性能为基准，或者以匹配系统性能为基准。指各个组件发挥到最大。

成本

用来升级，更换等提升组件性能时的时间，金钱，劳力等等。

基线的定义，以用户期望值为基础，可能会涉及以下因素

以往的经验，应用程序的基准，业界的标准，以前版本的情况

基线的表示方式，包括：每秒完成的批处理(作业)，每秒传输量，每秒数据量，磁盘扫描时间等等

分析影响性能的因素：

数据库设计（是否复合范式，是否合理归档、分区、分表等）

软件系统 （操作系统优化，数据库系统的配置，资源的规划和监控等）

硬件基础架构 （设备规格，硬件性能，负载均衡，容灾等）

Sql语句的写法、索引和统计信息，事务和锁，应用程序访问代码(连接过多、频繁开关等)

性能调优的顺序：

从左往右，从技术难度、成本、实效去考虑

DETECT 方法

发现问题、探究原因、提供可能的解决方法、执行最有可能的解决方案、确认是否成功解决(如果没有，重复前面的步骤)、完成其余的工作

DETECT方法论中的这些工作细分起来，会有很多，这里暂时不做过多描述。具体调优的步骤、性能调优工具的使用，下篇文章继续。