SQL Server应用程序性能调优

 SQL Server应用程序性能调优之硬件配置

  【IT168 专稿】当应用程序性能出现问题时，服务器硬件通常会背上黑锅，人们想到的往往是如何优化服务器的硬件。实际上恰恰相反，多数情况下，硬件并非导致性能问题的罪魁祸首。对于基于SQL Server的应用程序的性能和升级，服务器硬件所起的影响要远比人们想象的小。

  多数应用程序运行缓慢的原因是因为其糟糕的前期设计，而并非硬件性能不够。硬件通常被冠以恶名的原因是，在应用程序运行缓慢之前，性能问题通常不是那么显而易见。而且应用程序的设计不是说改就改的，人们解决性能问题最简单直接的办法就是提高其硬件性能。虽然这种办法也有一定效果，不过它不能真正完全解决问题，这也是为什么人们常常将性能低下归结为硬件问题的原因。虽然硬件有时候确实会导致性能问题，但多数情况下它却不是主要原因。

  第二篇：SQL Server应用程序性能调优之设计优化

  第三篇：SQL Server应用程序性能调优之SQL编程

  为了防止你的服务器硬件给SQL Server应用软件拖后腿，首先让我们简单看一下一些常见的硬件选择和调优问题。

  选择硬件

  为你的SQL Server应用选取最佳硬件要参照很多因素，诸如数据库的规模、用户的数量，数据库被使用的方式（OLTP或OLAP）等等。虽然没有成功的公式来估算服务器硬件需求，最好的办法就是在开发阶段提前开始测试你的应用。尽管许多有经验的DBA可以对你所需要的最佳硬件给出合理的估测，只有通过实际的测试才可确信满足你的应用需要的硬件是什么。

  在考察服务器硬件时，需要牢记以下硬件选择方面的事项：

  CPU：要购买可以扩展CPU数量的服务器。例如，通过测试结果你认为单CPU服务器就够用，那么你应该购买具备至少两个CPU安装空间的服务器，哪怕现在空着另一个CPU插槽的位置。预留下将来升级扩展的空间。

  内存：它可能是对SQL Server的性能影响最大的硬件部分。理想情况下，你的整个数据库应该可以fit into内存。不幸的是，这一般是不可能的。最低要求是，内存的大小应该能够容纳你的数据库中最大表，如果经济上可以接受，为服务器配备其能够支持大小的内存，换句话说，内存多了没坏处。

  I/O子系统：它对SQL Server性能的影响仅次于内存，也非常重要。最低要求是，使用硬件RAID系统来运行你的数据库。大概来说，你应该购买多个小硬盘，而不是一个大硬盘。在阵列中的硬盘数量越多，就可以获得更快的I/O。

  网络连接：在你的数据库服务器上，至少应该有一个百兆网卡，而且它应该连接到一个交换机上。理想情况下，服务器应该有两块网卡，通过全双工方式连接到交换机。

  调优服务器

  如果没有正确的配置和优化，最贵的服务器硬件未必具有最好的性能。我曾经遇到过很多硬件相关的性能问题，其多数原因是驱动未正确安装。这些硬件性能相关的问题中很多往往难于跟踪和解决。一般来说，应该让一个有经验的技术高手来确保硬件被正确安装和配置。然后，在该服务器被用于生产环境之前，在一定条件下测试你的应用程序，以发现潜在的性能问题。另外，你的操作系统也必须被正确的配置，这涉及到很多方面，在这儿无法具体介绍。

  为了在一个服务器获得最好性能，SQL Server应该独享一台服务器，而不应该同时还安装其它管理工具。不要为了省一点钱而将你的IIS或MTS服务器与SQL Server安装在同一台服务器上。这不仅仅会影响SQL Server的性能，而且使得性能调优和故障排查工作非常难于进行。

  优化SQL Server配置

  调优SQL Server的另一个常见误解是，为了获得最佳性能你必须定制优化它的多处配置。对于一些早期版本的SQL Server来说，这种做法或许有一定道理，但是对于最近版本的SQL Server，配置通常已经不再是一个问题，当然对于那些超大、超忙碌的服务器来说或许是另外一种情况。

  多数情况下，SQL Server可以自我调优。也就是说，SQL Server可以检查自己运行的任务，然后自动进行内部调整，以使指定任务获得尽可能高的性能。

  当你对SQL Server进行性能测试时，需要牢记SQL Server需要花一点时间来将自己调整到最优化。换言之，启动SQL Server服务后你立即获得的性能，与在有负载情况下运行几个小时后的SQL Server的性能是不相同的。因此在进行测试之前，要让SQL Server有一定时间来适应你的负载。

  通过企业管理器，或者sp_configure存储过程，你可以修改36个SQL Server配置选项。如果你没有调优SQL Server的丰富经验，我不建议你修改任何SQL Server的设置。如果你是一个新手，你所做的修改往往会适得其反，会降低SQL Server的性能。因为一旦修改了SQL Server的设置后，会使其丧失其自我调优的能力。

  如果经过深思熟虑后，你仍然认为修改一个或多个SQL Server配置可以提高其在特定环境下的性能，那么你应该稳妥谨慎的来对其进行修改。在你修改设置前，首先应通过诸如性能监视器之类的工具来了解当前SQL Server的性能，以其作为基准。每次只进行一处修改。不要一次进行多个修改，因为这样你无法明确每一个设置带来了性能上的什么变化。

  在进行了一处修改后，再次在相同负载下测量SQL Server的性能是否真正有所提高。如果没有，那么恢复到默认设置。如果的确有提高，再继续检查性能在其它负载下是否也会提高。通过后期测试，你或许会发现你的修改在某些负载下可以提高性能，但在其它负载下却会降低性能。这也是为什么我不推荐你修改多数设置的原因之一。

  一般来说，如果你的SQL Server应用程序遭遇到了性能相关问题，通过修改SQL Server设置方法解决这些问题的可能性非常小。

 

【IT168 专稿】优化你的应用程序设计

  如果你为应用程序使用了多层设计，SQL Server只是一个大型应用程序的一部分。多层设计的实现方式对应用程序性能影响之大，或许会远远超乎你的想象，它比SQL Server所带来的影响大的多。

  第一篇：SQL Server应用程序性能调优之硬件配置

  第三篇：SQL Server应用程序性能调优之SQL编程

  不幸的是，在应用程序性能低下时，人们往往将其原因归咎于SQL Server，而没有反思应用程序的设计，实际上很多情况下设计缺陷才是导致应用程序性能问题的主要原因。下面我提供一些可以帮助你进行应用设计的建议，以防止SQL Server继续独担性能低下的罪名。

  在设计多层应用时你首先需要决定的是，选择逻辑和物理设计。在这两种设计中，物理设计中最易发生导致性能问题的错误，原因是在这个设计中要完成理论在真实世界中的实现。和任何其它事情一样，你面临着多种选择，其中很多选择会带来升级或性能问题。

  为了确定哪一种选择才是正确的，需要你再次借助于测试手段，在设计阶段就开始早期潜在测试，你可以使用快速原型测试法，来判断哪一种实现可以最好的满足用户的需要。

  另外，当你在设计物理实现时，尽量遵循以下建议，来确保应用程序的可升级性和最优化性能：

  尽可能将以数据为中心的任务以存储过程的形式在SQL Server上完成。避免在展现层和业务层处理数据。

  不要在业务层保存修改状态数据，尽可能的在数据库中实现。

  不要创建复杂或难懂的对象分级。复杂类的创建和使用通常会比较耗资源，会降低应用程序的性能和扩展性。原因是当创建和释放这些对象时，内存分配操作的开销通常比较大。在进行应用程序设计时，可以考虑使用微软事务处理服务器（MTS）来充分利用数据库连接池和对象池的优势。MTS可以运行将数据库连接和对象都放到pool中，可以大大提高应用程序的整体性能和可扩展性。

  如果你的应用程序针对SQL Server的查询耗时较长，在设计应用程序时可以考虑异步进行查询。这样一个查询不用必须等待前面一条执行完后才能进行。将这个功能加入到你的多层应用软件的一个办法是使用微软消息队列服务器（MSMQ）。

  虽然按照以上建议并不能确保你获得一个可升级、快速执行的应用程序，却可以说是一个好的开始。

  优化数据库的设计

  与应用程序设计类似，数据库设计对SQL Server应用程序的可升级性和性能也非常关键。同样与应用程序设计类似，如果你在开始的时候没有合理的进行数据库设计，当应用程序被投入到生产环境中后，再对其进行修改往往非常困难，且代价较高。在设计SQL Server数据库时，以下几件事情对其升级和性能非常关键，需要牢记。

  同样的道理，你需要尽可能早的使用真实数据来测试你的设计。这意味着你需要开发具有示例数据的原型数据库，然后使用预计会在真实应用中发生的行为类型来对该设计进行测试。

  一开始就需要你确定的设计原则之一是，数据库将被使用来进行联机事务处理（OLTP），还是在线分析处理（OLAP）。在设计数据库时人们常犯的一个最大错误是，试图设计数据库同时满足OLTP和OLAP需要。如果你希望获得高性能和可扩展性，这两种应用程序类型是互相排斥的。

  OLTP数据库通常是高度规格化的，有助于降低必须存储的数据量。存储的数据越少，SQL Server执行的I/O操作就越少，数据库访问就会越快。事务处理也尽可能在短时间内完成，以减少锁定冲突现象。最后一点，为降低大量插入、更新和删除操作的开销，要尽可能少的使用索引。

  另一方面，OLAP数据库则是高度反规格化的。另外，它不使用事务处理，因为数据库是只读的记录锁定不是什么问题。当然，为了满足广泛的报表需求，需要大量使用索引。

  由此可见，OLTP和OLAP数据库实现的目的完全不同，你不可能设计一个数据库同时满足这两种需求。

  在数据库设计早期阶段发现问题后，修改起来相对比较容易，因此不要等到应用程序开发完成后，再去修改数据库设计，这几乎是不可能的。

 

 

【IT168 专稿】如何优化应用程序的SQL Server编程

  现在，应用程序和数据库设计应该已经完成，而且都使用快速原型技术进行了性能和可扩展性的测试。现在我们需要为应用程序编写与SQL Server协同的代码。

  第一篇：SQL Server应用程序性能调优之硬件配置

  第二篇：SQL Server应用程序性能调优之设计优化

  如何进行应用程序编程，对性能和可扩展性也有很大影响，就如同数据库设计和整体应用程序设计对性能的影响一样。有的时候，选择一个更适合的简单编程技巧就可以带来较大的性能提高。实现一个任务的代码可能有很多种，不过获得最优性能的往往只有一个。

  如何优化你的T-SQL代码

  和任何编程语言一样，T-SQL提供了多种方式来实现同一个任务。其中有的方法所实现的性能要高于其它方法。在这一部分中，我将向大家介绍一些编写高性能T-SQL代码的诀窍。

  选择合适的数据类型：数据类型选择好，可以大大提高SQL Server执行SELECT、INSERT、UPDATE和DELETE操作的速度。不过，选择最优的数据类型并不总是一件很简单的事情。在创建SQL Server物理表的时候，以下建议可以有助于获得最优性能。

  选择能满足你需要的最小数据类型。例如，如果某一列需要存储的是数字1到10，那么该列的数据类型选择TINYINT会比INT更好。CHAR和VARCHAR的选择也是遵循同样的原则。另外，对于字符列的字符数不要设定太大，满足自己需要就可以，这样SQL Server能够在其数据和索引页面中存储更多行记录，降低读取它们时所需的I/O次数。另外，它将减少从服务器移动到客户端的数据量，降低网络流量和延时。

  如果某一列的文本数据在长度上差别很大，使用VARCHAR数据类型来取代CHAR数据类型。尽管VARCHAR数据类型比CHAR数据类型的开销略微有些大，但是使用VARCHAR数据类型可以大大节省空间，可以降低I/O，提高整体SQL Server性能。

  除非你需要存储Unicode数据，不要使用NVARCHAR或NCHAR数据类型。它们所占用的空间是VARCHAR或CHAR的两倍，可以增加服务器I/O开销。

  如果你需要存储较大的字符串数据，而且它们不超过8000字符，那么最好使用VARCHAR数据类型，而不要使用TEXT数据类型。TEXT数据类型开销较大，会降低性能。

  如果有一列只用来存储数字，使用数值型数据类型，诸如INTERGER，而不要使用VARCHAR或CHAR数据类型。Numeric数据类型一般会需要较小的空间来存储数值。这样有助于降低数据列的大小，而且当列内容被搜索或与其它列联合时，可以提高性能。

  谨慎使用触发器

  在T-SQL中，触发器是一个强大的工具，但是由于它们每次被执行的时候，需要对表进行INSERT、UPDATE或DELETE操作，这可能带来大量开销。以下是如何优化触发器性能的一些技巧。

  保持触发器中的代码最精简以降低开销。触发器中运行的代码越多，它所进行的每一个INSERT、UPDATE和DELETE就会越慢。

  不过某个任务可以使用更高效的技术实现，就不要使用触发器。

  尽量不要使用回滚触发器，因为其相关开销太大。与其让触发器发现问题后对事务处理进行回滚操作，不如在它进入触发器之前就捕获该错误。与让触发器回滚相比，在触发器启动之前提前发现错误会消耗更少的服务器资源。