读书笔记（三）：【SQL Server 2005 Performance Tuning性能调校】（1）：【性能调校概观】

　　2010.01.03，今天开始看这本书，刚看了第一章就已经有了共鸣的感觉，可能是因为我之前有过两个性能优化项目的经验吧，其实感觉最重要的一点就是在第二个项目优化的过程中刻意去做一些总结，希望接下来的阅读会有更多这个的共鸣出现。（期待中。。。）

　　网络上没有这本书的电子版，只有两章的免费试读，进入试读地址，唉，真不知道以后要像这样引用文章该如何办啊？！

　　下面是在阅读过程中感觉比较重要的内容，并加入了自己的一些体会：

【1】出现的一个名词“平行运算”，SQL的平行运算

　　平行运算 又名 并行计算（Parallel Computing）

　　并行计算（Parallel Computing）是指同时使用多种计算资源解决计算问题的过程。为执行并行计算，计算资源应包括一台配有多处理机（并行处理）的计算机、一个与网络相连的计算机专有编号，或者两者结合使用。并行计算的主要目的是快速解决大型且复杂的计算问题。此外还包括：利用非本地资源，节约成本 ― 使用多个“廉价”计算资源取代大型计算机，同时克服单个计算机上存在的存储器限制。

【2】性能调优需要哪些技能

　　性能调校不是一件简单的事，一般来说需要有广泛的经验与知识，不单单是数据库的经验，还要对商业逻辑、系统架构设计、编写应用程序、操作系统、架设网络环境、使用各种侦测与监控工具程序、安全与防毒等，都有基本的了解，才能在复杂的系统中，找到症结所在。

 　　体会：还是比较赞同这些知识结构的，我们要有目的地学习这几个方面的知识，打开视野，对调优也是有好处的。 

【3】摘要：

　　因此要做好性能调校，你需要期待自己不但要深入专精的知识，而且要对相关知识保持高度的兴趣，可以广泛涉猎各个方面的技能，同时能够与人合作。

  　　体会：以前一直认为优化知识修改几个代码里面的循环语句，修改几条SQL语句（把批量的数据库操作修改成类似于Insert Select等）就能了事了，虽然这样成功优化了两个系统（并没有完全优化，只是做研究或者叫练手，因为要求并不高，只要能比以前有大的性能改进就可以了），但是一直没有想过string与StringBuilder也会有这么大的性能问题，而且网上已经有很多人讨论这个问题，而我却没有关注过，惭愧啊，所以.Net的知识也需要加深啊。

【4】摘要：

　　性能问题在开发的程序中就需要注意，尤其是数据库的设计，若是数据库设计不良，事后要再修改，可能会牵动整个程序架构，所以，一开始做好数据库的设计就非常重要。当然，数据库不应该让前端程序代码直接访问数据表，而是要通过视图（view）、存储过程（stored procedure）或用户自定义函数（user define function）来访问，这样可以提高数据表的扩充性。
　　整个应用程序的开发最好先快速建立测试系统（prototype），让用户在开发程序中一再测试，以循环递增的方式屡次修正问题，提早发现潜藏的性能问题，在开发程序中解决性能问题要比系统完成，交付后才发现性能问题，而后需要大改来得好。

 　　体会：对使用视图我并不完全赞同，视图是可以降低系统的耦合，也有效的对表字段进行了权限控制，我们平常使用视图的主要目的就是联合多个表，方便查询；但是这样的话，表中的索引如何有效地使用呢？

　　即使SQL Server2005可以对视图进行索引，但是也有缺点，第一个是不方便，有限制；第二，如果视图比较大，索引造成磁盘空间会大大增大；

　　有时可以考虑使用存储过程，这样就可以使用表的索引了，又可以对字段进行控制，也可以比较大的解耦，又可以有执行缓存，貌似这个方案不错，但是如果什么都靠存储过程，第一很容易就有存储过程风暴；第二对分页支持不太好；第三，我们的程序的逻辑变化会比较大，写存储过程对业务逻辑的维护比较麻烦。

　　有时遇到大的逻辑处理，我们会把一些必要的数据先查询出来，在进行编码逻辑处理，在进行组装，生成一个逻辑数据。所以我们要根据不同的需求来确定使用方法。

【5】性能基线

调校性能的第一个工作应该是建立性能的基线（baseline），所需的类型有：
　　·昔日系统正常运行时的数据。
　　·调校前系统的各种数据。
　　·用户希望达到的目标。
基线是用来比较的，任何性能调校的动作都应该依凭数据，不要诉诸情绪。

 　　体会：在优化公司的第二个项目的时候就自己感悟到基线了，所以这点我也是很赞同的，是一个性能测试和优化的前期需要做的工作。

　　因为有了基线才好做对比，做比较，也才会有成就感。

【6】摘要

　　笔者遇到的大部分状况是管理者会挑眼前最节约成本的事情先做。一般来说，就是要工程师着手调架构，可能是数据库的设计，也可能是程序代码重载，忙了个把月后声明失败，最后还是花钱买机器。这种仅看当前最低成本的做法有几个弊端：
　　·用户苦等一两个月，最后还是换机器，他们会觉得工程师能力不足。
　　·实际上浪费了人力成本。
　　·一阵子后，性能问题又再度浮现。

 　　体会：事前的整体评估很重要，关系到成本和各户交互中的重要作用。

【7】摘要：

　　除了以文档描述基线、调校的目标外，还可以以文档描述所用的工具，如评估性能的程序、真实应用程序的片段功能、各种资源的性能监视程序、压力测试程序等。同时，有越详细的步骤越好。性能调校可能是一再的错误尝试，因为大部分的状况都是扑朔迷离的，无法一眼看出问题所在，需要改改这个，看看是否比较好，再修修那个，看看结果如何。若没有文档记录，你可能会在性能调校的大迷宫中打转，做一些类似而重复的事情，但总理不出头绪。

　　尝试列出系统中各个组件合理的性能消耗，可以帮助你理清整个系统访问中，各个组件所占的性能消耗比例，哪些部分有可以调整的空间。另外，再搭配调整该部分的成本有多高，让你了解调整的优先级，并对系统的极限有更佳的认识。

 　　体会：对这段描述是比较赞同的。

　　这也得从优化公司的第二个项目说起，那个时候就做了比较多的前期工作，比如测试、基线、文档、分析、猜想、评估等工作，最后的优化就花了一天的时间，虽然还没有优化全部的内容，但是性能还是有了很大的提高的。

　　优化后的总结也是很重要的，可以把优化过程记录下来，沉淀一些知识，这次我就总结出一个比较通用的优化流程，改天帖出来。

【8】摘要

性能调校的步骤——DETECT
现将各步骤的原文列出如下：
　　Discover the problem：发现问题。
　　Explore the conditions：探究原因，为问题提供明确的定义与定位。
　　Track down possible approaches：提供可能的解决方案。
　　Execute the most likely approach：执行最有可能的解决方案。
　　Check for success（如果需要的话，重复之前的步骤）：确认解决方案成功与否。
　　Tie up loose ends：完成收尾的工作。

 　　体会：<1>：这才发现我之前一个项目的优化步骤和这个有80%的相似度（在看这本书之前），这让我小小开心了一下。

　　　　　 <2>：这再一次证明了我的观点：在开始学一些新知识的时候，一定要先自己动手去尝试，不要一开始就买一个《XX入门》之类的书籍来看。

　　　　　 <3>：需要注意一点就是，在接下来的实践中，有意识的去看看文中的描述是否可以借鉴，通过这样的方式来完善自己的那套调优步骤。

【9】摘要

　　探究原因，为问题提供明确的定义与定位

　　确定用户的问题与需求后，下一步是探究原因，此步骤的重点是“探索（Explore）”、“找寻证据（Evidence）”、“建立（Establish）”描述整个问题来龙去脉的假设。

　　当你从以上步骤确切了解用户的问题后，就需要建立问题发生原因的假设和导致性能不足的运行模型，而当前这个步骤便是在搜集证据，以建立并确认该假设。在这个阶段中，你可以通过SQL Server Management Studio、SqlDiag.exe、性能计数器、事件查看器、SQL Profiler、SQL Server 2005 Performance Dashbord Reports、DMV与DMF等工具来找线索（以上工具在本书第3章“性能调校相关工具程序”中有详细说明）。

　　这个步骤的主要任务是广泛搜集相关数据，但并未深入分析数据间的关联性，这是下一步骤要做的事情。当然，要搜集正确而相关的证据，难免要稍做分析，但不要过度耗时在某项单一的事件上。此步骤要的是全貌，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键现象而误入歧途。

　　当然，若在这个阶段就发现重大问题，一眼就看出关键点，例如，硬件毁损，某个硬盘区间或内存区间不稳，某个程序吃掉所有的内存，让SQL Server无内存可用，抑或是该程序常常出问题，拖垮CPU等，则可以跳过DETECT方法论之后的步骤，进行深入探讨这个问题并予以解决。

　　通常性能调校并不是那么容易一眼看出重大错误，或许用户自己就可以解决，而需要专门做性能调校的情况可能如战场上不断带来的伤患，第一步要做的是决定伤患的轻重，再决定如何利用有限的资源做最有效的治疗。当你在前一步获得用户大量的问题后，接下来就要搜集并探究各种现象，决定轻重缓急，通盘考虑后，进入下一步。

 　　体会：摘取这段是有目的的，它说明了几个知识点：

　　　　第一，建立假设命题；

　　　　第二，可以看到性能的检测使用了那些工具；

　　　　第三，并不深入分析，稍作分析，不耗时在某个问题上；

　　　　第四，决定轻重缓急；第五，对一眼就能看出问题予以解决。（个人补充：不过要回去证明，也就是狭义上的回归测试）

【10】摘要

　　性能调校的专家们在接受访问时，表示他们最常用的技巧是“二分查找”，也就是“‘区分’之后再加以‘克服’（Divide and Conquer）”。它可以应用在前画所述的DETECT 方法论中，尤其是在“提供可能的解决方案”这一步。我们需要在巡回的程序中分出有用的信息，利用二分法将问题局限在某个范围，尤其在问题芜蔓庞杂的情况下，要能分解问题，通过已有的知识与信息，剔除较不可能的部分。

二分法的局限
　　·二分查找算法的局限是数据必须要有顺序才能做二分查找。同样地，你对于系统的知识要具备广泛的连续性，才能在问题发生时，分析问题所在的位置。
　　·第二个局限是你无法知道是否不小心把问题隔离在目标区域以外了，只好从头再来，这样会让你丧失信心。
　　·最后一个局限性，也是最大的问题所在：某些性能问题不单纯地以本来的面目呈现，因此分解问题时，可能会被现象蒙蔽。

 　　体会：这一段入选的原因就是：在我的头脑里面就没有调优可以使用“二分查找”这样的概念，虽然文中也说了一些缺点，但是有机会我还是会去尝试一下，看看是否有道理的，不过估计希望不大。

【11】摘要

　　完成收尾的工作
　　前5个步骤循环重复地执行，每一次循环的结果都更逼近问题的核心，直到达到性能调校的目标。

　　但当我们完成目标后，依然要注意以下的问题：
　　·解决的方式是否有边际效应而造成其他的问题？
　　　　例如，为了某类的查询工作建立了大量的索引，事后原本正常的添加、修改、删除都出现了性能问题。
　　·是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚？
　　　　建立问题的假设时，很容易将问题特殊化，仅局部地解决该问题。例如，加了某个索引或稍稍改变查询语句，舒缓了当前的瓶颈，但当用户稍微增加或采用不同的查询方式时，老问题就容易复发。
　　·是否要建立持续跟踪的计划？
　　　　当你无法确定已经根除问题时，那可能就要拟定持续跟踪的计划了。决定是否要持续观察某些计数器，跟踪某些现象是否还会发生，若发生了要如何解决等。如此不但可以让用户安心，更可以让你知道之前的行为到底有多少效益，下次的性能调校才能提出更完整的解决方案。

 　　体会：这里说到的几点可能是我们平时会忽略的问题，感觉第一点最重要了。比如在调优的过程中发现是代码的问题，那么在修改代码的过程就会对原来逻辑进行修改（例如原来是对数据库进行循环操作造成的性能问题，那么调优方案就可能是进行批量操作数据），这种时候就无形中修改了原来的逻辑，这个时候我们要对新的逻辑进行必要的测试，其中包括功能测试和性能测试。

【12】对上面Detect方法的总结：

　　·对问题的简单描述；

　　·建立基线；

　　·假设（个人术语：猜想）；

　　·决定轻重缓急；

　　·假设问题的计划，解决问题的计划；

　　·验证假设；

　　·拟定新的计划；

　　·到底有多少效益；

【13】调优基本流程图

 

【14】“华丽的总结”

　　性能调优的核心思想：就像中学的时候，给自己出一个命题，自己再去证明这个命题。（呵呵，很生动吧。O(∩_∩)O~）

【15】欢迎大家对“【4】”提出自己的看法，大家一起讨论下。