20.1 優(yōu)化時機(jī)

http://book.51cto.com ?2010-06-17 11:50 ?楊華/騰靈靈譯 ?清華大學(xué)出版社 ?我要評論(0)

• 摘要：《SQL Server 2008高級程序設(shè)計》第20章設(shè)計性能卓越的數(shù)據(jù)庫，本章是同一問題--設(shè)計(在性能成為問題之前解決它)--的兩個不同方向中的第一個方向。本節(jié)為大家介紹優(yōu)化時機(jī)。
• 標(biāo)簽：SQL Server??程序設(shè)計??SQL Server 2008高級程序設(shè)計

第20章 設(shè)計性能卓越的數(shù)據(jù)庫 從作為作者的角度來講，本章可能是本書中最難寫的一章，不過這不是由一般的原因引起的。通常，這里的問題是如何通過易懂的方式講述復(fù)雜的內(nèi)容。隨著鄰近本書的結(jié)尾，希望我在這點上是成功的--盡管還有很多值得改進(jìn)的地方。從以往的經(jīng)驗和本書中已經(jīng)介紹的主題來看，到目前為止讀者應(yīng)該已經(jīng)對本章將要討論的主題有了堅實的基礎(chǔ)。這意味著筆者可以相對自由地講述事情的本質(zhì)，而不需要太過擔(dān)心會引起混淆。 那為什么書寫本章對我來說是十分困難的呢？因為確定把哪些內(nèi)容放入本章以及后面的姊妹章節(jié)該講述哪些內(nèi)容確實是非常困難的。讀者可以看到，這并不是一本講述性能優(yōu)化的書--性能優(yōu)化本身就可以寫一本書了。這是一本幫助你在使用SQL Server的開發(fā)中獲得成功的書。擁有一個性能卓越的系統(tǒng)對于成功是至關(guān)重要的。問題就像Bob Seger歌曲中所唱的那樣："要有所為，有所不為(what to leave in, what to leave out)"。這里要把注意力集中在哪里才會最有幫助呢？ 對于性能優(yōu)化而言，也許最重要的事情是必須要明白不可能做到全知全能。如果你是一位普通的SQL Server開發(fā)者，那么只要知道其中的20%就已經(jīng)是很幸運(yùn)的了。幸運(yùn)的是，性能調(diào)優(yōu)是適用80-20法則(20%的正確工作能夠帶來80%的收益)的領(lǐng)域之一。 在本書的這一版中將會對這一主題稍作展開，在結(jié)構(gòu)化決策的基礎(chǔ)上添加了"如何發(fā)現(xiàn)可以進(jìn)行性能優(yōu)化的地方"相關(guān)的內(nèi)容。本章中大部分的內(nèi)容都是之前已經(jīng)討論過的主題，包括： 索引選擇 客戶端處理和服務(wù)端處理 策略上的反規(guī)范化 組織存儲過程 使用臨時表 使用重復(fù)性進(jìn)程分步完成任務(wù)與使用長時間運(yùn)行的進(jìn)程一次性完成任務(wù) 讀者可能會認(rèn)為本章中討論的內(nèi)容實際上是屬于設(shè)計的范疇，因為它們本質(zhì)上是有點結(jié)構(gòu)性的。在大多數(shù)情況下，這些主題都是已經(jīng)討論過的，但是本章著重關(guān)注其性能部分。下一章將會介紹如何處理系統(tǒng)已經(jīng)存在的情形(維護(hù)、位置放置問題以及規(guī)劃將來的變更)。 然而，一個共同的觀點是讀者應(yīng)該兩個章節(jié)都閱讀：本章只是一個開始。在性能方面最大的事情實際上是停下來并思考一下。由于某些奇怪的原因，在使用SQL時有一種傾向，即采用第一次出現(xiàn)在腦海中的方案往往會成功。讀者需要使用與完成任何其他開發(fā)工作相同的思考方式去處理查詢、存儲過程以及數(shù)據(jù)庫設(shè)計。還需要記住的是T-SQL代碼只是系統(tǒng)的一部分--硬件、客戶端代碼、SQL Server配置以及網(wǎng)絡(luò)問題等都是"代碼之外"的因素，它們可能對系統(tǒng)產(chǎn)生極大的影響。 注意： 性能對于不同的人來說意味著不同的事情。例如，很多人把它想成簡單的響應(yīng)時間(查詢完成得多快)。還有一個概念是對性能感覺上的體驗(很多用戶關(guān)注要多久才能接收到足夠的數(shù)據(jù)以開始工作，而不是完成整個查詢需要多久)。另一種看法可能專注于伸縮性(例如，在響應(yīng)時間遭受影響之前或者知道用戶之間開始互相影響之前，到底能在系統(tǒng)上加多大的負(fù)載？)。 兩個介紹性能的章節(jié)中很多示例和建議都是關(guān)于原始速度的--返回結(jié)果的速度有多快--但是在適當(dāng)?shù)牡胤綍婕案兄阅芎蜕炜s性問題。確保在設(shè)計中已經(jīng)考慮了性能的所有方面--不僅僅是完成時間。 20.1? 優(yōu)化時機(jī) 好吧，這可能看起來有點顯而易見，但是在整個開發(fā)過程中，對性能的考慮要遠(yuǎn)遠(yuǎn)早于編寫代碼。實際上，對性能的考慮應(yīng)該從需求收集過程就開始，并且永遠(yuǎn)不會結(jié)束。 在需求收集階段有關(guān)性能調(diào)優(yōu)的最重要的方面是什么呢？現(xiàn)在，這個時候無法物理地對系統(tǒng)進(jìn)行調(diào)優(yōu)，但是從邏輯上對系統(tǒng)進(jìn)行調(diào)優(yōu)可以做的事情有很多。例如，客戶到底是關(guān)注感知性能呢還是更加關(guān)注作業(yè)真正的完成時間？對于交互式過程來說，如果讓他們知道一些事情正在發(fā)生(即使只有一個進(jìn)度條)，那么一般來說他們會更加滿意并且認(rèn)為系統(tǒng)速度較快。此外，只要讓系統(tǒng)的"首個響應(yīng)"--即它什么開始輸出內(nèi)容--更快一點，那么讓整個過程完成得稍微慢一點也是值得的。在需求收集階段應(yīng)該弄清楚哪些方式是較好的。最后，在需求收集界面應(yīng)該確定系統(tǒng)的性能需求。 提示： 很多時候，筆者見過很多開發(fā)人員認(rèn)為"足夠快"的系統(tǒng)對用戶來說其性能是無法接受的。導(dǎo)致這種情況發(fā)生的原因有很多，不過最常見的原因肯定是開發(fā)人員在逃避現(xiàn)實。 找到用戶期待的東西！還要記住在類似真實的硬件上進(jìn)行實際的負(fù)載--不是一兩個開發(fā)人員坐在他們的開發(fā)系統(tǒng)前面進(jìn)行測試所產(chǎn)生的負(fù)載--測試以確定是否達(dá)到了預(yù)期的性能。 顯然，在設(shè)計階段還要考慮性能問題。如果在設(shè)計時考慮了性能，那么一般來講在系統(tǒng)完成之后性能調(diào)優(yōu)所需的工作量將會大大減少。此外，所能達(dá)到的"最佳"數(shù)字也有可能會被極大地增強(qiáng)。 這里需要再強(qiáng)調(diào)一下，性能考慮永遠(yuǎn)不會停止--在真正開始編碼，并且代碼能夠正常工作后便停下來！停下來看看代碼。一旦整個系統(tǒng)集成起來后，幾乎不用再看實際的代碼了，除非： 有些地方出問題了(存在bug)。 需要升級系統(tǒng)的一部分。 存在明顯的性能問題(通常是非常糟糕的問題)。 在前兩種情況中，可能不需要關(guān)心性能問題，只需要關(guān)心如何修正bug或者添加額外的功能。這里想要說的是花額外的幾分鐘時間看一下自己的代碼，然后問自己"能夠做得更好一點嗎？"或者"嗨，我在這里做了什么愚蠢的事情嗎？"，然后可以在這里或那里進(jìn)行一些修改，并且有時候還可以在其他地方進(jìn)行較多的修改。 提示： 簡單地說：我犯了愚蠢的錯誤，你也會犯這些錯誤。但是，如果回過頭來花一兩分鐘以挑剔的眼光看一看自己的代碼，并且說"嗨，真不敢相信我會這樣做"，你會對這種事情發(fā)生的頻率感到驚訝的。希望那種情形是很少發(fā)生的，但是如果花時間對代碼進(jìn)行審查，那么將會發(fā)現(xiàn)大多數(shù)可能會導(dǎo)致系統(tǒng)性能下降的關(guān)鍵問題。至于那些沒有發(fā)現(xiàn)的問題，下一章將會解決這類問題！ 下一個較大的測試?yán)锍瘫畷r間點是在質(zhì)量保證階段。在這個時刻應(yīng)該建立常規(guī)的系統(tǒng)基準(zhǔn)并將它同在需求階段建立的性能需求進(jìn)行比較。 最后，但并不是最不重要的--永不停止。詢問一下最終用戶，從性能角度來看，他們感到最痛苦的事情是什么。他們說哪些東西比較慢嗎？不要等他們告訴你(通常，他們會認(rèn)為"這本來就是這樣的"并且不會對你說什么--當(dāng)然，除了你老板)，直接去問。 【責(zé)任編輯：云霞 TEL：（010）68476606】
職場 IT 休閑

0

分享

微博 QQ 微信

收藏

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

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

轉(zhuǎn)載于:https://blog.51cto.com/2189440bop58/496747

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。