原地址：http://www.cnblogs.com/gaizai/archive/2010/01/04/1638325.html
?
2010.01.03，今天開始看這本書，剛看了第一章就已經有了共鳴的感覺，可能是因為我之前有過兩個性能優化項目的經驗吧，其實感覺最重要的一點就是在第二個項目優化的過程中刻意去做一些總結，希望接下來的閱讀會有更多這個的共鳴出現。（期待中。。。）
網絡上沒有這本書的電子版，只有兩章的免費試讀， 進入試讀地址 ，唉，真不知道以后要像這樣引用文章該如何辦啊？！
下面是在閱讀過程中感覺比較重要的內容，并加入了自己的一些體會：
?
【1】出現的一個名詞“平行運算”，SQL的平行運算
平行運算 又名 并行計算（Parallel Computing）
并行計算（Parallel Computing）是指同時使用多種計算資源解決計算問題的過程。為執行并行計算，計算資源應包括一臺配有多處理機（并行處理）的計算機、一個與網絡相 連的計算機專有編號，或者兩者結合使用。并行計算的主要目的是快速解決大型且復雜的計算問題。此外還包括：利用非本地資源，節約成本 ― 使用多個“廉價”計算資源取代大型計算機，同時克服單個計算機上存在的存儲器限制。
?
【2】性能調優需要哪些技能
? 體會：還是比較贊同這些知識結構的，我們要有目的地學習這幾個方面的知識，打開視野，對調優也是有好處的。?
?
【3】摘要：
?? 體會：以前一直認為優化知識修改幾個代碼里面的循環語句，修改幾條SQL語句（把批量的數據庫操作修改成類似于Insert Select等）就能了事了，雖然這樣成功優化了兩個系統（并沒有完全優化，只是做研究或者叫練手，因為要求并不高，只要能比以前有大的性能改進就可以 了），但是一直沒有想過string與StringBuilder也會有這么大的性能問題，而且網上已經有很多人討論這個問題，而我卻沒有關注過，慚愧 啊，所以.Net的知識也需要加深啊。
?
【4】摘要：
整個應用程序的開發最好先快速建立測試系統（prototype），讓用戶在開發程序中一再測試，以循環遞增的方式屢次修正問題，提早發現潛藏的性能問題，在開發程序中解決性能問題要比系統完成，交付后才發現性能問題，而后需要大改來得好。
? 體會：對使用視圖我并不完全贊同，視圖是可以降低系統的耦合，也有效的對表字段進行了權限控制，我們平常使用視圖的主要目的就是聯合多個表，方便查詢；但是這樣的話，表中的索引如何有效地使用呢？
即使SQL Server2005可以對視圖進行索引，但是也有缺點，第一個是不方便，有限制；第二，如果視圖比較大，索引造成磁盤空間會大大增大；
有時可以考慮使用存儲過程，這樣就可以使用表的索引了，又可以對字段進行控制，也可以比較大的解耦，又可以有執行緩存，貌似這個方案不錯，但是 如果什么都靠存儲過程，第一很容易就有存儲過程風暴；第二對分頁支持不太好；第三，我們的程序的邏輯變化會比較大，寫存儲過程對業務邏輯的維護比較麻煩。
有時遇到大的邏輯處理，我們會把一些必要的數據先查詢出來，在進行編碼邏輯處理，在進行組裝，生成一個邏輯數據。所以我們要根據不同的需求來確定使用方法。
?
【5】性能基線
·昔日系統正常運行時的數據。
·調校前系統的各種數據。
·用戶希望達到的目標。
基線是用來比較的，任何性能調校的動作都應該依憑數據，不要訴諸情緒。
? 體會：在優化公司的第二個項目的時候就自己感悟到基線了，所以這點我也是很贊同的，是一個性能測試和優化的前期需要做的工作。
因為有了基線才好做對比，做比較，也才會有成就感。
?
【6】摘要
·用戶苦等一兩個月，最后還是換機器，他們會覺得工程師能力不足。
·實際上浪費了人力成本。
·一陣子后，性能問題又再度浮現。
? 體會：事前的整體評估很重要，關系到成本和各戶交互中的重要作用。
?
【7】摘要：
嘗試列出系統中各個組件合理的性能消耗，可以幫助你理清整個系統訪問中，各個組件所占的性能消耗比例，哪些部分有可以調整的空間。另外，再搭配調整該部分的成本有多高，讓你了解調整的優先級，并對系統的極限有更佳的認識。
? 體會：對這段描述是比較贊同的。
這也得從優化公司的第二個項目說起，那個時候就做了比較多的前期工作，比如測試、基線、文檔、分析、猜想、評估等工作，最后的優化就花了一天的時間，雖然還沒有優化全部的內容，但是性能還是有了很大的提高的。
優化后的總結也是很重要的，可以把優化過程記錄下來，沉淀一些知識，這次我就總結出一個比較通用的優化流程，改天帖出來。
?
【8】摘要
現將各步驟的原文列出如下：
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】摘要
二分法的局限
·二分查找算法的局限是數據必須要有順序才能做二分查找。同樣地，你對于系統的知識要具備廣泛的連續性，才能在問題發生時，分析問題所在的位置。
·第二個局限是你無法知道是否不小心把問題隔離在目標區域以外了，只好從頭再來，這樣會讓你喪失信心。
·最后一個局限性，也是最大的問題所在：某些性能問題不單純地以本來的面目呈現，因此分解問題時，可能會被現象蒙蔽。
? 體會：這一段入選的原因就是：在我的頭腦里面就沒有調優可以使用“二分查找”這樣的概念，雖然文中也說了一些缺點，但是有機會我還是會去嘗試一下，看看是否有道理的，不過估計希望不大。
?
【11】摘要
前5個步驟循環重復地執行，每一次循環的結果都更逼近問題的核心，直到達到性能調校的目標。
但當我們完成目標后，依然要注意以下的問題：
·解決的方式是否有邊際效應而造成其他的問題？
例如，為了某類的查詢工作建立了大量的索引，事后原本正常的添加、修改、刪除都出現了性能問題。
·是否真正根除了問題，還是僅表象地頭痛醫頭，腳痛醫腳？
建立問題的假設時，很容易將問題特殊化，僅局部地解決該問題。例如，加了某個索引或稍稍改變查詢語句，舒緩了當前的瓶頸，但當用戶稍微增加或采用不同的查詢方式時，老問題就容易復發。
·是否要建立持續跟蹤的計劃？
當你無法確定已經根除問題時，那可能就要擬定持續跟蹤的計劃了。決定是否要持續觀察某些計數器，跟蹤某些現象是否還會發生，若發生了要如何解決等。如此不但可以讓用戶安心，更可以讓你知道之前的行為到底有多少效益，下次的性能調校才能提出更完整的解決方案。
? 體會：這里說到的幾點可能是我們平時會忽略的問題，感覺第一點最重要了。比如在調優的過程中發現是代碼的問題，那么在修改代碼的過程就會對原 來邏輯進行修改（例如原來是對數據庫進行循環操作造成的性能問題，那么調優方案就可能是進行批量操作數據），這種時候就無形中修改了原來的邏輯，這個時候 我們要對新的邏輯進行必要的測試，其中包括功能測試和性能測試。
?
【12】對上面Detect方法的總結：
·對問題的簡單描述；
·建立基線；
·假設（個人術語：猜想）；
·決定輕重緩急；
·假設問題的計劃，解決問題的計劃；
·驗證假設；
·擬定新的計劃；
·到底有多少效益；
?
【13】調優基本流程圖
?
?
【14】“ 華麗的總結 ”
性能調優的核心思想：就像中學的時候，給自己出一個命題，自己再去證明這個命題。（呵呵，很生動吧。O(∩_∩)O~）
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
