性能調校的工作千頭萬緒，最怕的就是像無頭蒼蠅般盲目地錯誤嘗試（ 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。是否要建立持續跟蹤的計劃？
當你無法確定已經根除問題時，那可能就要擬定持續跟蹤的計劃了。決定是否要持續觀察某些計數器，跟蹤某些現象是否還會發生，若發生了要如何解決等。如此不但可以讓用戶安心，更可以讓你知道之前的行為到底有多少效益，下次的性能調校才能提出更完整的解決方案。
