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】
職場 IT 休閑

0

分享

微博 QQ 微信

收藏

上一篇：詳解谷歌官方教程 Android... 下一篇：尋找迷失在Windows中的Ub... 51bom

492篇文章，19W+人氣，0粉絲

轉載于:https://blog.51cto.com/2189440bop58/496747

總結

以上是生活随笔為你收集整理的20.1 优化时机的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。