20.1 优化时机
http://book.51cto.com 2010-06-17 11:50 杨华/腾灵灵译 清华大学出版社 我要评论(0)
- 摘要：《SQL Server 2008高级程序设计》第20章设计性能卓越的数据库，本章是同一问题--设计(在性能成为问题之前解决它)--的两个不同方向中的第一个方向。本节为大家介绍优化时机。
- 标签：SQL Server 程序设计 SQL Server 2008高级程序设计
第20章 设计性能卓越的数据库
从作为作者的角度来讲，本章可能是本书中最难写的一章，不过这不是由一般的原因引起的。通常，这里的问题是如何通过易懂的方式讲述复杂的内容。随着邻近本书的结尾，希望我在这点上是成功的--尽管还有很多值得改进的地方。从以往的经验和本书中已经介绍的主题来看，到目前为止读者应该已经对本章将要讨论的主题有了坚实的基础。这意味着笔者可以相对自由地讲述事情的本质，而不需要太过担心会引起混淆。
那为什么书写本章对我来说是十分困难的呢？因为确定把哪些内容放入本章以及后面的姊妹章节该讲述哪些内容确实是非常困难的。读者可以看到，这并不是一本讲述性能优化的书--性能优化本身就可以写一本书了。这是一本帮助你在使用SQL Server的开发中获得成功的书。拥有一个性能卓越的系统对于成功是至关重要的。问题就像Bob Seger歌曲中所唱的那样："要有所为，有所不为(what to leave in, what to leave out)"。这里要把注意力集中在哪里才会最有帮助呢？
对于性能优化而言，也许最重要的事情是必须要明白不可能做到全知全能。如果你是一位普通的SQL Server开发者，那么只要知道其中的20%就已经是很幸运的了。幸运的是，性能调优是适用80-20法则(20%的正确工作能够带来80%的收益)的领域之一。
在本书的这一版中将会对这一主题稍作展开，在结构化决策的基础上添加了"如何发现可以进行性能优化的地方"相关的内容。本章中大部分的内容都是之前已经讨论过的主题，包括：
索引选择
客户端处理和服务端处理
策略上的反规范化
组织存储过程
使用临时表
使用重复性进程分步完成任务与使用长时间运行的进程一次性完成任务
读者可能会认为本章中讨论的内容实际上是属于设计的范畴，因为它们本质上是有点结构性的。在大多数情况下，这些主题都是已经讨论过的，但是本章着重关注其性能部分。下一章将会介绍如何处理系统已经存在的情形(维护、位置放置问题以及规划将来的变更)。
然而，一个共同的观点是读者应该两个章节都阅读：本章只是一个开始。在性能方面最大的事情实际上是停下来并思考一下。由于某些奇怪的原因，在使用SQL时有一种倾向，即采用第一次出现在脑海中的方案往往会成功。读者需要使用与完成任何其他开发工作相同的思考方式去处理查询、存储过程以及数据库设计。还需要记住的是T-SQL代码只是系统的一部分--硬件、客户端代码、SQL Server配置以及网络问题等都是"代码之外"的因素，它们可能对系统产生极大的影响。
注意：
性能对于不同的人来说意味着不同的事情。例如，很多人把它想成简单的响应时间(查询完成得多快)。还有一个概念是对性能感觉上的体验(很多用户关注要多久才能接收到足够的数据以开始工作，而不是完成整个查询需要多久)。另一种看法可能专注于伸缩性(例如，在响应时间遭受影响之前或者知道用户之间开始互相影响之前，到底能在系统上加多大的负载？)。
两个介绍性能的章节中很多示例和建议都是关于原始速度的--返回结果的速度有多快--但是在适当的地方会涉及感知性能和伸缩性问题。确保在设计中已经考虑了性能的所有方面--不仅仅是完成时间。
20.1 优化时机
好吧，这可能看起来有点显而易见，但是在整个开发过程中，对性能的考虑要远远早于编写代码。实际上，对性能的考虑应该从需求收集过程就开始，并且永远不会结束。
在需求收集阶段有关性能调优的最重要的方面是什么呢？现在，这个时候无法物理地对系统进行调优，但是从逻辑上对系统进行调优可以做的事情有很多。例如，客户到底是关注感知性能呢还是更加关注作业真正的完成时间？对于交互式过程来说，如果让他们知道一些事情正在发生(即使只有一个进度条)，那么一般来说他们会更加满意并且认为系统速度较快。此外，只要让系统的"首个响应"--即它什么开始输出内容--更快一点，那么让整个过程完成得稍微慢一点也是值得的。在需求收集阶段应该弄清楚哪些方式是较好的。最后，在需求收集界面应该确定系统的性能需求。
提示：
很多时候，笔者见过很多开发人员认为"足够快"的系统对用户来说其性能是无法接受的。导致这种情况发生的原因有很多，不过最常见的原因肯定是开发人员在逃避现实。
找到用户期待的东西！还要记住在类似真实的硬件上进行实际的负载--不是一两个开发人员坐在他们的开发系统前面进行测试所产生的负载--测试以确定是否达到了预期的性能。
显然，在设计阶段还要考虑性能问题。如果在设计时考虑了性能，那么一般来讲在系统完成之后性能调优所需的工作量将会大大减少。此外，所能达到的"最佳"数字也有可能会被极大地增强。
这里需要再强调一下，性能考虑永远不会停止--在真正开始编码，并且代码能够正常工作后便停下来！停下来看看代码。一旦整个系统集成起来后，几乎不用再看实际的代码了，除非：
有些地方出问题了(存在bug)。
需要升级系统的一部分。
存在明显的性能问题(通常是非常糟糕的问题)。
在前两种情况中，可能不需要关心性能问题，只需要关心如何修正bug或者添加额外的功能。这里想要说的是花额外的几分钟时间看一下自己的代码，然后问自己"能够做得更好一点吗？"或者"嗨，我在这里做了什么愚蠢的事情吗？"，然后可以在这里或那里进行一些修改，并且有时候还可以在其他地方进行较多的修改。
提示：
简单地说：我犯了愚蠢的错误，你也会犯这些错误。但是，如果回过头来花一两分钟以挑剔的眼光看一看自己的代码，并且说"嗨，真不敢相信我会这样做"，你会对这种事情发生的频率感到惊讶的。希望那种情形是很少发生的，但是如果花时间对代码进行审查，那么将会发现大多数可能会导致系统性能下降的关键问题。至于那些没有发现的问题，下一章将会解决这类问题！
下一个较大的测试里程碑时间点是在质量保证阶段。在这个时刻应该建立常规的系统基准并将它同在需求阶段建立的性能需求进行比较。
最后，但并不是最不重要的--永不停止。询问一下最终用户，从性能角度来看，他们感到最痛苦的事情是什么。他们说哪些东西比较慢吗？不要等他们告诉你(通常，他们会认为"这本来就是这样的"并且不会对你说什么--当然，除了你老板)，直接去问。
【责任编辑：云霞 TEL：（010）68476606】
