生活随笔
收集整理的這篇文章主要介紹了
20.1 优化时机
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
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)容還不錯,歡迎將生活随笔推薦給好友。