[转]性能调优的步骤
性能调校的工作千头万绪，最怕的就是像无头苍蝇般盲目地错误尝试（ trial and error ），不但旷日费时，还累积不到经验，团队与个人都难以成长，也就是说下次再碰到性能议题时，还是乱试一通。
我们需要拟定计划、有步骤分阶段地执行，如此才能循序渐进，一步步朝目标前进。据微软的研究显示，过程应该分为 6 个阶段，分别是发现、探究、提案、执行、复查、收尾。这不一定适用于任何调校的情境，笔者从来也没有完全这么做，但却是个可供参考的方法论，能据以修正成自己的方法。有固定的准则后，才可以累积经验并加以分门别类。
现将各步骤的原文列出如下：
- Discover the problem ：发现问题。
- Explore the conditions ：探究原因，为问题提供明确的定义与定位。
- Track down possible approaches ：提供可能的解决方案。
- Execute the most likely approach ：执行最有可能的解决方案。
- Check for success （如果需要的话，重复之前的步骤）：确认解决方案成功与否。
- Tie up loose ends ：完成收尾的工作。
1.3.1 各阶段重点说明
以下对各阶段稍做说明。
1.3.1.1 发现问题
这可能是支持性能调校的专家们花时间最少的一个阶段，因为大部分的工作都是用户在做，他们可能已经有一大堆的观察经验，而找你来，不会期望你完全重做一遍他们已经做过多次的事情，而是希望看到你马上采取一些行动，并一针见效。
这个阶段专业与否就看你是否可以立刻找到重点，把握住各个细节，而不是在整个调校的各个程序中，来来回回、反反复复询问相同的问题。这个阶段最重要的就是发现（ Discover ）问题、详述（ Describe ）问题，并且正确而详细地记录下来（ Document ）。在进入下一步骤前，你应该问问自己以下这些问题。
对于问题是否已经有简明的描述
若无法简明地描述问题，代表你尚不了解问题，或者没抓到重点。这是很有可能的，因为用户常拉拉杂杂地说了一大堆，让你晕头转向，只好急着做点东西，不见得是有方向，只是想摆脱用户像倾倒垃圾一样，噼里啪啦地描述现象时，还夹缠着抱怨与谩骂，大家一拥而上，对你一股脑儿地说个不停。信息虽然多，但零零碎碎看不到全貌。
你可以尝试将自己听到的，重新有序地整理一遍再诉说给用户听，看看是否符合大家共通的观点，若没有异议，就有了一个大致正确的开始。
用户的基线与期待在哪
在前面一节中强调了基线的重要，这让你可以比较成果，并有前进的目标。例如，当用户抱怨“ SQL Server 跑得太慢了”，这时要理清他们的“慢”是怎么定义的，而什么是合理可接受的速度。若没有基线，则需要你为他们建立。
性能调校可能是一再循环的过程，除了时间难以掌握外，还不一定所有的问题都有解。不要让用户有错误或过高的期待，从而能减少承担不可能完成任务的压力，更可减少长时间调校后，达不到用户期望而招致的愤怒。
在查找的过程中尽量不要急躁或恐慌，贸然进入到下一个步骤，只会让你再一次回到原点，重新定义问题。
1.3.1.2 探究原因，为问题提供明确的定义与定位
确定用户的问题与需求后，下一步是探究原因，此步骤的重点是“探索（ Explore ）”、“找寻证据（ Evidence ）”、“建立（ Establish ）”描述整个问题来龙去脉的假设。
当你从以上步骤确切了解用户的问题后，就需要建立问题发生原因的假设和导致性能不足的运行模型，而当前这个步骤便是在搜集证据，以建立并确认该假设。在这个阶段中，你可以通过 SQL Server Management Studio 、 SqlDiag.exe 、性能计数器、事件查看器、 SQL Profiler 、 SQL Server 2005 Performance Dashbord Reports 、 DMV 与 DMF 等工具来找线索（以上工具在本书第 3 章“性能调校相关工具程序”中有详细说明）。
这个步骤的主要任务是广泛搜集相关数据，但并未深入分析数据间的关联性，这是下一步骤要做的事情。当然，要搜集正确而相关的证据，难免要稍做分析，但不要过度耗时在某项单一的事件上。此步骤要的是全貌，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键现象而误入歧途。
当然，若在这个阶段就发现重大问题，一眼就看出关键点，例如，硬件毁损，某个硬盘区间或内存区间不稳，某个程序吃掉所有的内存，让 SQL Server 无内存可用，抑或是该程序常常出问题，拖垮 CPU 等，则可以跳过 DETECT 方法论之后的步骤，进行深入探讨这个问题并予以解决。
通常性能调校并不是那么容易一眼看出重大错误，或许用户自己就可以解决，而需要专门做性能调校的情况可能如战场上不断带来的伤患，第一步要做的是决定伤患的轻重，再决定如何利用有限的资源做最有效的治疗。当你在前一步获得用户大量的问题后，接下来就要搜集并探究各种现象，决定轻重缓急，通盘考虑后，进入下一步。
1.3.1.3 提供可能的解决方案
在深入分析前述两步骤搜集到的数据，并对整个问题的前因后果提出假设，进而拟出对应策略，如果前一个步骤做得不够详实，就可能误判，导致努力了半天，但没有碰到瓶颈点。
在拟定策略时，应当参考大量的在线说明、 Knowledge Base ，在网络上广泛查找资料，看看前人或是微软对于你所面对的问题是否有好的方案。到相关网站讨论区提出问题，或是询问技术顾问，最好不要闭门造车，防止解决问题时又出现新问题。
这个步骤最重要的是拟定计划，而这又可分为两个部分：用来证明对问题所建立的假设的计划，以及解决问题的计划。前文一再强调，性能调校可能是个一再循环的过程，有一个好的计划，你才能知道方向与步骤。
不要冲动地进入到下一步骤，信息界有句名言：“最早开始的，最晚结束”。言下之意就是凡事要谋定而后动，若匆忙进入到下一步执行解决方案，可能因为疏失而导致更多的错误，甚至因为你的操作让系统更为不稳定，原本性能不佳的系统宕掉了，这时会招致用户更大的不满。
1.3.1.4 执行最有可能的解决方案
这可能是 DETECT 方法中最简单的一步，因为只要执行上一步中所拟定的计划即可。但是在执行计划时，仍然要注意系统的反应，随时都可能会要放弃当前的计划，因为新的证据可能证明先前的判断是错误的，因而要修正计划，甚至是退回到重新拟定计划。
随时反省，不要急着操作。每一步愈稳也就愈少反复，因此，现在的时间花费可以节省未来的时间（ Spend time now to save time later ）。整个性能调校的过程就是在考验团队的细心与耐力、知识的广度与深度，切勿急躁。
在这一部分执行的计划也有二个，分别是上一步拟定的：其一是对问题的假设，验证某些行为导致性能不足的计划；其二是解决问题的计划。先证明假设成立，再执行解决该问题的方案。若假设错误，当然就不需要执行解决方案。否则努力地重载了程序、变更了数据库架构、买了新的硬件等，却是验证了瓶颈点不在此，结果就尴尬了。
同时要小心观察你的计划会不会导致新的问题，并严重影响当前系统的执行，不要原来是系统迟缓，而你的测试却成了压垮骆驼的最后一根稻草。
1.3.1.5 确认解决方案成功与否
执行计划后，需要重新收集数据，以验证该计划成功与否。这一步骤又分两个阶段，第一阶段是确认计划是否证实了假设，若证实假设是对的，则需要继续搜集相关的数据，以确立接下来的步骤。
第二阶段是分析已收集到的数据，看看是否解决了优先级最高的瓶颈，若已解决，应有瓶颈转移的现象，此时要针对次要瓶颈开始拟定新的计划，并确定是否已经符合用户的目标。
如果执行结果不如预期，证明假设错误，会非常让人气馁。
其实，定错性能调校的目标是常有的事，这时就是要你在错误的面前，停下来好好思考，不要立刻行动。查看先前步骤的各项产出，重新理出头绪，最重要的是清楚知道这一回的错误在哪，如此新的步骤就会更逼近目标。犯错是常有的事，踩着错误走向成功是性能调校的常态。现在，你可以休息一下，喝杯咖啡，和合作伙伴放轻松，回顾一下这个过程，对整个问题建立更清晰的轮廓。
1.3.1 .6 完成收尾的工作
前 5 个步骤循环重复地执行，每一次循环的结果都更逼近问题的核心，直到达到性能调校的目标。
但当我们完成目标后，依然要注意以下的问题。
1。解决的方式是否有边际效应而造成其他的问题？
例如，为了某类的查询工作建立了大量的索引，事后原本正常的添加、修改、删除都出现了性能问题。
2。是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚？
建立问题的假设时，很容易将问题特殊化，仅局部地解决该问题。例如，加了某个索引或稍稍改变查询语句，舒缓了当前的瓶颈，但当用户稍微增加或采用不同的查询方式时，老问题就容易复发。
3。是否要建立持续跟踪的计划？
当你无法确定已经根除问题时，那可能就要拟定持续跟踪的计划了。决定是否要持续观察某些计数器，跟踪某些现象是否还会发生，若发生了要如何解决等。如此不但可以让用户安心，更可以让你知道之前的行为到底有多少效益，下次的性能调校才能提出更完整的解决方案。
摘自胡百敬著作《SQL Server 2005 performance tunning性能调校》
