-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

京東--收獲,不止SQL優化——抓住SQL的本質(特別版)

( 簡體 字)
作者:梁敬彬,梁敬弘類別:1. -> 資料庫 -> SQL語言
譯者:
出版社:電子工業出版社京東--收獲,不止SQL優化——抓住SQL的本質(特別版) 3dWoo書號: 46789
詢問書籍請說出此書號!

缺書
NT售價: 440

出版日:5/1/2017
頁數:488
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787121314360
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:


這是自上一本《收獲,不止Oracle》一書后,我第二次為作者寫序,我知道這又是一本極不尋常的書。
果然,初翻開此書,就給我帶來了驚喜。作者將全書脈絡展現得非常清晰,先在前言中通過小故事梳理出SQL優化的方法論,接下來將各SQL優化的知識點融入到方法論中,形成了全書目錄,從而讓讀者明白為什么要講解這些知識,學了這些知識對優化有什么幫助。更讓人稱道的是,這個目錄是以一個生動有趣的足跡圖展現在讀者面前的,不落俗套的同時給人一種視覺上的驚艷感。這是誰的足跡,分明是你自己的足跡!于是,一種強烈的代入感油然而生,來,邁開雙腿,學習著,思考著,奔跑著!
足跡所到之處,感動如影隨形,只因案例無數。我看到了作者十多年如一日在工作的荊棘之路中勇往直前的精神,看到了作者在攻堅克難后的沉思總結,看到了作者作為感動福富十大人物的一種堅持的精神!更難得的是,這些實戰案例背后密布的代碼不但沒讓我迷糊,反倒讓我覺得非常親切,因為本書為每個章節的案例都進行了詳細的分類和匯總,讓人一目了然。
翻開此書,作者極佳的文字表現能力和技術實力立刻躍然紙上,讀者一定會感嘆作者怎么具備將晦澀難懂的技術書寫得如此清新脫俗的能力!不過我卻一點都不感到意外,始終是抱著一種驗證的心態來閱讀,其中的原因來自于他在公司的雙重身份。梁敬彬是福富特級專家,又是公司四星級內訓師,前者的榮譽顯示了IT人的輝煌技術成就,后者的勛章證明了老師的杰出教學能力,兩者一完美結合,書中再多的驚喜也不會使你感到意外了。我看到IT企業中有很多技術牛人由于在表達溝通交流方面的欠缺,在傳幫帶方面做得不夠好;也看到很多技術人員具備良好的溝通能力卻苦于技術不過硬而無法與人深入交流。作者在這方面給我們廣大IT技術人員樹立了一個很好的榜樣,會打硬仗還要會帶兵。據統計每年接受梁敬彬培訓的福富技術人員多達400人,加上他每年在公司以外的演講和技術分享,梁老師可謂桃李滿天下,給梁老師點個大大的贊!
隨著對此書的進一步了解,我知道作者邀請了業界許多專家對此書進行完善、美化、審核。至此,我又讀出了一種精神,叫“團隊精神”,此書正是團隊協作的結晶!作者把工作中的團隊精神帶入書籍編寫中,值得稱道。我在感嘆此書的不同凡響之余,更感慨團隊的無窮力量!
此書必將成為IT書籍的又一個經典傳奇,我相信廣大讀者在翻閱此書時,除了可以學到精妙的SQL優化實用技術外,還可以從無數案例中感受到什么叫激情、震撼;從方法論總結上理解什么叫升華、用心;從各種梳理的表格和思維導圖中體會什么叫清晰、極致;從書的精妙視覺設計中領悟什么叫求道、協作。我想說的是,從菜鳥到SQL大師其實不易,真正的大師不止是技術上精湛,還需要一種精神。這種精神,還請你在閱讀本書中感悟吧!
福富軟件公司副董事長 楊林

匠心獨運 獨樹一幟
——與梁敬彬先生序
在拿到敬彬新書的稿件時,我的腦海第一時間呈現出來的就是這八個字:匠心獨運,獨樹一幟。
技術書籍的寫作也是一個創作過程,平庸者千篇一律,卓越者自出機抒。
寫作一本千篇一律的書很容易,而要想自出機抒,形成自己的風格,并且為讀者認可,則是難上加難。而敬彬的系列作品,已經形成了自己獨特的風格,并且為廣大技術愛好者們所喜愛,這不獨是匠心所在,更是隱現宗師風范。
如作者所說,有數據庫就有SQL,而SQL又因其靈活、復雜,而讓眾多應用系統飽受性能之苦。我一直認為,在開發環節提高SQL質量才是數據庫優化的治本良方,SQL審核也是DevOps理念在數據庫領域的最佳落地點,云和恩墨也在此保持持續的關注并研發了產品。敬彬的新書從SQL入手,以其獨特的故事演繹法,讓SQL優化成為了一種趣味,書中還通過實例打破了以訛傳訛的種種法則,讓讀者獲得思想上的自由。
這是一本活的書,活躍的思想,活潑的行文,活動的二維碼,活靈活現的音視頻,互聯網時代,原來書還可以這樣寫。
快點來一起體驗吧!
蓋國強
云和恩墨創始人,Oracle ACE總監,ACOUG主席


前言與意識:從優化方法到全書脈絡
嘆IT之一入深似海
傳說:一入IT深似海,從此菜鳥淚成河。
老師,搞IT真有傳說中的這么慘嗎,那我從此要珍愛生命遠離IT了。
我們慢慢聊吧。話說這時代啊,應該是最好的時代了。知識的獲取相當便利,基本上沒有什么知識點是Goolge、百度等搜索引擎搜不到的;此外,現在的技術書籍、教學視頻也非常豐富。除了自學手段外,我們甚至還可以在論壇上提問,或者參加各種線上和線下的培訓。當今時代,IT學習成本越來越低,門檻似乎一點都不高!
對啊,那咋說深似海淚成河呢?
其實這話也是有道理的。我們來說說這個時代的IT系統,其和從前也大不相同了,現在對外的IT系統大多需要同時支持電腦終端和手機終端(手機終端進一步分為Android和iOS等操作系統),此外還要考慮各個接口,如關聯業務接口、短信接口、微信接口、公安接口、銀行接口……系統顯然比以前更復雜了。這意味著系統開發在功能實現方面的難度更大了,而系統實現難度大又意味著對IT開發人員要求更高了!
嗯,好像是這樣。
其實不止是IT系統功能實現的難度變大。你想想看,現在幾乎人人都有手機,手機端的接入就意味著成千上萬的人可以隨時隨地拿起手機訪問系統,這給系統帶來了可怕的訪問量。此外,不可避免地會出現同一時刻大量用戶同時訪問某應用的景象,這又帶來了巨大的并發量。因此系統如果沒有良好的性能規劃,很容易垮掉。所以說IT開發人員的壓力不僅是實現難,還會遭遇性能瓶頸。當然,IT運維人員的壓力更大,因為假如系統有問題,他們首當其沖。
哇,好像還真是如此,聽得我手心出汗了。
前面我們談到了功能實現困難,又提到性能瓶頸壓力,現在我再提一點,即定位困難。還記得之前我說的接口嗎?隨著時代的發展,各種IT應用已從孤島走向關聯。比如你的系統是計費系統,當要對用戶進行計費時,你可能要從客服系統中獲取用戶的套餐等資料,或許還要去網廳系統完成……這下問題來了,假如應用有故障,你知道問題出在哪嗎?是你自己的系統出問題,還是接口的系統出問題?再比如,你好不容易定位出是自己系統的問題,那請問,到底是數據庫、前端應用還是中間件的問題呢?
老師,有沒有手帕,我擦擦臉上的汗。
假如你已經知道系統的問題出在數據庫。那請問,是SQL還是其他問題,你如何定位,如何判斷?再假如你通過努力判斷出是SQL問題,那該如何優化,是動手改寫呢,還是不用改寫,加加索引啥的……
老師,要考慮的方方面面太多了,看來我是把IT系統想簡單了。
剛討論的話題,放在以前,是基本不用擔憂的,這是時代高速發展帶來的問題。接下來你換一個角度想想,這個時代越來越多的人依賴IT系統,你的系統一旦出現問題,多少用戶會受到影響?這個時代越來越多的IT系統之間有關聯,你的系統一旦出現問題,多少別人的系統會受到影響?怎么樣,是不是又感受到另一層面的壓力了。
哇,看來這時代IT人尤其是IT菜鳥的日子真的不好過啊!一入IT深似海,從此菜鳥淚成河。
結論:
當今時代的IT系統復雜度高、數據量和并發量大、關聯性強,無論是定位解決故障還是應用開發維護,難度都比較大,并不是一件輕松的事情。
贊IT之SQL地位高
你也吟上這詩了,別傷感,這不也有好事嘛,我之前就說過如今學習比以前容易很多。
說的也是,我都忘記了,還好還有這點值得安慰。
真是如此嗎?好吧,以IT學習中的SQL優化為例,你知道如何進行學習嗎?
這個我知道,SQL優化主要是看執行計劃,比如發現是不合理的全表掃描,就設法轉成索引掃描等。
說得有點簡單啊。其實SQL本不需要優化,就是因為前面我們所說的當今IT系統復雜度高、訪問量和并發量都大,而數據又是IT應用中訪問的熱點,因此這些壓力自然就體現在IT系統對應的數據庫模塊上,所以SQL需要優化。
哦,原來如此,明白了。
任何IT系統,數據都是核心,同時也是訪問和展現的熱點,脫離數據庫的IT項目幾乎不存在,甚至可以說幾乎沒有不需要進行數據庫操作的編程人員,而能與數據庫進行無縫交互的就只有SQL了。此外,SQL是一種學起來非常容易的“傻瓜語言”,隨便一個where條件就是一個需求實現,基本上新手級別的開發人員坐下來看看簡單語法即可編寫SQL,如果有3天時間邊做邊學,基本上所有SQL都會編寫了。用我本人的例子來說吧,有人忽然問我學SQL開發學了多久,我幾乎是本能般從嘴里冒出一句:SQL開發,我有花時間學嗎,寫SQL難道不是自然而然就會了嗎?
正因為SQL如此重要,學習成本又如此之低,同時與IT系統中不可或缺的數據庫交互起來渾然天成,所以幾乎所有Java、C等開發人員都能較熟練應用數據庫SQL開發技術。這導致應用SQL開發的人在數量上異常龐大,簡單地說,就是所有前后端程序開發人員和IT運維人員以及數據庫開發人員的總和!
于是在高訪問量、高并發的IT系統數據庫模塊中,平均每秒運行成千上萬條SQL的場景已成常態。在這種情況下,這些SQL如果運行較慢,便容易迅速拖垮整個IT系統,因此SQL優化就變得特別重要了。此外,由于SQL過多,不可能僅靠一兩個SQL專家筋疲力盡地調優,我們便可以高枕無憂了。最有效的方式是,每個SQL編寫人員自己要有SQL優化的意識和本領!
老師,我在項目組里做Java開發,確實也涉及大量的SQL開發,您說得沒錯,我也感覺SQL開發特簡單,不過我的SQL經常跑得很慢,您說SQL優化好學嗎?
結論:
數據是IT系統的核心、重中之重,而SQL是數據交互的必然手段,所以SQL的應用非常廣泛,使用人群數量也非常龐大,因此SQL的重要性不言而喻!
涌SQL之優化淚水
SQL優化肯定比SQL編寫本身要難很多,但也存在一些優化的基礎知識,如SQL執行計劃、索引原理,等等。這些都比編寫SQL本身要復雜得多,因此要成為SQL優化高手僅知道一些優化基礎知識是遠遠不夠的,還需要經驗的沉淀,并且要轉化成你的方法論。
老師,您能否舉例說明一下需要什么經驗嗎?
不妨我回答得更有趣點吧,先給你說幾個SQL優化的小故事,其中奧妙我們后續探討。
太好了!
嗯,你邊聽邊思考。故事1:話說某天上午小王被告知某系統的一個菜單訪問非常慢,于是他開始介入優化,他跟蹤到該菜單調用的具體SQL,接下來他通過觀察該SQL的執行計劃發現該SQL訪問某張表時沒走索引,覺得該表應該加一個索引,他花了整整1個小時發現這個問題后非常興奮,于是馬上動手開始建索引了。建索引大致花費了幾分鐘時間,隨后他發現SQL走索引了,并且真的快了許多。于是測試一下該菜單,果然快了不少。故事1講完了。
啥,講完了,太短了吧,您這說的是優化成功案例嗎?
是否成功一會兒再下結論,接下來說故事2。話說小王優化效果杠杠的,正自鳴得意時,被告知雖然這個菜單變快了,不過剛才有持續幾分鐘時間出現訪問該菜單一直報錯的情況,隨后正常。
老師,這啥意思,為啥應用程序會出錯,怎么就恢復了。您故事2講完了嗎,怎么您的故事都這么短啊?
嗯,現在開始說第3個故事了。當天下午小王又接到電話,被告知那菜單訪問又慢了。小王有點吃驚,于是趕緊登錄系統運行該SQL,發現確實變慢了,不過奇怪的是該SQL正常走索引,沒什么問題啊,小王很是郁悶。正在他束手無策之時,小王又接到電話,說該菜單又快了。暈,他現在可是啥都沒做,這是咋回事?當晚,小王輾轉反側,無心睡眠。第2天小王又接到電話……他崩潰了。
好可憐啊。然后呢?
繼續第4個故事。話說小王崩潰之后無法正常工作,于是領導把這難題交給其他人處理了,小王得知后滿血復活再度投入工作中。幾天后小王又迎來一個新任務,開發項目組中有一條SQL很慢,希望能優化一下。小王看了一眼覺得寫得歪瓜裂棗樣很不舒服,于是挽起袖子對SQL進行重寫,改改改!
然后呢?
小王改好后,滿懷期待的開發組對新的SQL一運行,發現跑得比之前的SQL還要慢很多!
可憐,小王又崩潰了吧,接下來呢?
嗯,說故事5吧。在小王再度崩潰之前,公司的SQL優化大師老丁正好路過,他分析了之后,建議將SQL語句涉及的某表的外鍵加上索引。后來大家照辦了,果然性能迅速提升!老丁告訴小王,優化前可通過各種手段先觀察觀察SQL涉及的表結構、索引等,看它們有無不合理之處,急于動手改造SQL太盲目了,是沒有抓住主要矛盾的體現,而且改代碼需要測試、打補丁、上線,也是一件很辛苦的事。小王頻頻點頭,謹記老丁教誨。
看來小王成長了。
是嗎?那我們繼續說故事6。
一周后小王又面對一條SQL需要優化,這次他不動手改寫了,嘗試了加索引,又嘗試了調整表結構,結果提升效果非常不明顯……
然后呢,又崩潰了?
好在老丁又及時出現了,他這次沒有修改表結構,而是和開發人員進行了半小時的交談,然后居然對SQL進行重寫,改改改!然后 SQL就變得飛快了。小王傻眼了,不是說盡量不著急先動手改SQL嗎?怎么老丁一看到這SQL就改改改。悲催啊,該怎么做才是對的!讓小王悲催的還不止這個,老丁的新SQL看上去并不是很復雜,可是小王居然看不懂老丁為什么能這么改寫。
沒錯,看不懂!他看不懂老丁寫什么,也完全不理解新舊SQL的等價性。
可憐的人!老師,我覺得不是“一入IT深似海,從此菜鳥淚成河。”而是“一入SQL深似海,從此優化淚成河。”
結論:
SQL優化不是一件容易的事,明明優化后變快了,結果不一會兒又慢了。有時不改寫可以解決問題,有時又必須要改寫才能解決問題。讓人難以適應。
析SQL之優化淚水
你故事聽完了,啥感想,就是覺得小王好慘,優化很難嗎?
嗯,差不多吧。
好吧,讓我來解讀一下這些故事吧。故事1里小王能定位到具體SQL,并且能根據SQL執行計劃進行SQL優化,這至少說明了小王還是掌握了一定的SQL優化基礎技能的,否則估計執行計劃是什么都沒有聽過。不過接下來的故事2和故事3說明他是失敗的。為啥呢?那是因為他經驗太少,同時也缺乏由經驗轉換而成的做事方法論。
我是怎么下的這個結論呢?你注意到沒,小王他接到電話后就開始動手優化了。他難道不應該多問一句這問題是一直以來就存在呢,還是今天忽然出現的。
老師,問這有啥用呢?
如果是第一次出現,你可能就會關注一下是否昨晚系統做了啥動作,比如昨晚打了一個補丁,這補丁引發這次故障的可能性就非常大,于是目標就很清晰了。在實在無法解決的情況下,回退補丁也是一個思路。而如果是經常有這故障,那應該有其他同事處理應對過,獲取他們之前的分析成果,或者收集之前的日志和現在進行比對,這些難道對小王沒幫助嗎?
老師,事實上是不是因為晚上打補丁導致的?
你可以認為是,也可以認為不是。我說明一下,這幾個故事沒有真相,只是解讀一下。真相不重要,你猜測的過程就是你進步的過程。另外這里小王是加了一個索引,你覺得這個動作是對的還是錯的?
老師,我覺得應該是錯的,因為在第3個故事里,他加索引后,系統雖然前期變快,但是后來又慢了。我覺得這個加的索引沒有用,或者至少是沒有解決全部問題。不過我就是奇怪為啥時快時慢?
這沒啥奇怪的,我們還是進行假設。你不覺得可能有這么一種情況,此時整個系統都非常地慢,根本不只是這個菜單慢。求助者沒有提出其他模塊慢或許只是因為他平時僅用這個菜單,那你想想,如果整個平臺都癱瘓了,局部能快起來嗎?
哦,這我怎么一點都沒想到啊!
嗯,我只是說可能性。那為什么整個數據庫都慢?可能性更多了,比如數據庫主機上某些應用程序耗盡了主機的CPU、內存等資源,數據庫運行在這臺主機上,覆巢之下安有完卵? 接下來解釋為啥忽快忽慢問題,正常啊,如果這些害人的應用程序有時運行,有時結束,結束時數據庫不就正常了?
原來如此啊,第3個故事里的小王崩潰得好冤啊,如果知道事實的真相,他把數據庫主機的程序停了或者優化了或者移到別的地方去,就解決問題了。
你的這個解決方案非常棒,不過別忘了我這里不說真相,一切都是可能性解讀。當然這些可能性猜測是基于經驗和推理的,也不是完全沒依據的。另外,故事2里描述菜單曾經出錯了幾分鐘,你注意到并思考過為什么了嗎?
有的,不過這是為啥呢?
你沒注意到建索引也是幾分鐘時間嗎?幾乎可以肯定地說,是這個建索引動作導致的故障。因為建索引會鎖全表,這時候更新數據肯定會失敗。小王犯了一個大錯,在業務高峰期做DDL操作,嚴重地影響了生產,問題解決者成了麻煩制造者。這故事2倒是不需要推測的,真相一定如此。
哇,這么嚴重的錯誤原來是小王一手造成的,我還真沒想到。
嗯,再說故事4吧,小王動手改改改,然后效果差差差,這里我們可以解讀到什么呢?那就是解決問題要有目的性,不能沒找到真正原因盲目動手。你看他覺得SQL寫得不好,就改。實際上應該觀察慢在什么地方,比如可以通過執行計劃看出最大的開銷在某全表掃描上,而該全表掃描完全可以通過索引減少訪問路徑,這時加索引就可以解決問題,改寫SQL不可能解決問題的。
哦,確實如此。
接下來,在故事5里,老丁果然只是增加了索引后就解決了性能問題。優化SQL不一定非要改寫才可以優化,有時根據數據庫的體系邏輯結構不改寫SQL也可完成優化。改寫SQL的代價也更高,因為現實中如果你要改SQL肯定需要經過測試、打補丁、上線等多個過程,不可能直接就在生產中修改。
最后看故事6,小王學習老丁只調整參數進行SQL優化。接下來劇情反轉了,小王學老丁不改,效果差差差。而老丁則動手改改改,效果又是杠杠的。小王欲哭無淚,不知自己該如何做了。其實這里小王生搬硬套了,他沒有找到本質原因,比如此時可能是由于冗長的寫法導致表訪問了多次,而老王改寫SQL將表訪問次數大幅度降低下來。這時不改寫是無法優化的。又或者是老丁根據業務需求,砍掉了某些多余的邏輯,這就更需要改寫SQL了。
哦,老師您總結得很到位啊!
由于不改寫通常來說比改寫高效,而不改寫的優化一般都和數據庫的體系邏輯架構有關。因此我們需要認真學習這部分基礎知識,這也就是老師的SQL優化課程中為什么會涉及這部分知識的原因。不過能不改寫優化固然好,有時等價改寫也是必需的,而且改寫其實分成兩個部分:一個是等價改寫;一個是根據業務改寫。比如小王看某SQL寫得很不順眼,然后動手改改改,這顯然是等價改寫。而老丁和開發人員交談了半個多小時,改造后的SQL連小王都看不明白,這就很可能是根據業務改寫的。
明白了,原來如此。
業務改寫是優化的最高境界,老丁通過和開發人員交流后發掘出真正的需求,然后寫出來的代碼表面上看和舊代碼邏輯完全不等價,實際卻等價。
哦,老師您能否解釋一下什么叫真正需求?
好吧,還是講生動點的例子吧。從前我曾經講過一個《小余買魚》的故事。小余媽媽一個勁地讓小余買魚招待客人,條件不允許的時候還堅持如此。后來小余讓媽媽用冰箱里的牛肉來代替魚,媽媽也猛然醒悟了,她忘記了需求的本質是做美味給大家分享。站在做美味這角度上看,去老遠的地方買魚和拿冰箱里的牛肉,又有什么區別呢?
我明白了,沒有提煉到這層需求的人,真的很難理解吃牛肉和吃水煮魚其實是一樣的,如果代碼改寫前后表面上有這么大差距,也難怪小王會大惑不解。
是的,這里順便再說一點,小王看不懂老丁寫的SQL,也可能是因為老丁用了某些可能小王沒見過的SQL語法來改寫,我們這里稱之為高級SQL。比如WITH子句、樹形遞歸、分析函數,等等。
哦,好想見識一下。
結論:
其實這一節想說的就是,做事要有方法論,要先整體后局部,解決問題要注重效率,先盡量考慮不改寫的優化,再考慮改寫的優化。而不改寫的優化靠的是體系結構知識的沉淀,而改寫則要考慮邏輯等價改寫和業務改寫兩大思路,其中業務改寫是SQL優化的最高境界。另外還是要有一定的知識沉淀,高級SQL的語法也要掌握,其在很多場合下能幫上我們大忙。
規范流程的重要性
其實小王的系列故事還暴露了他身上一個非常重要的缺陷,那就是做事缺乏流程、缺乏規范。先不說解決問題的方法論,小王在系統中建了索引后導致系統出現問題,就是犯了一個不規范操作的低級錯誤。這應該在DBA的工作流程中是明確禁止操作的。當然小王有權限做這件事也是值得深究的,這種權限是不是要管控得更嚴格一些?這里涉及到了作業流程規范。
接下來小王手忙腳亂地進行優化,是不是都很有序?他要花一小時時間才定位到某處需要建立索引,如果建索引有依據的規范并且能快速被體檢報告診斷出來,他需要花一小時嗎?這里涉及到了數據庫的設計規范。
故事中還涉及到SQL改寫優化的過程,如果性能低下的SQL在運行之前能被事先撈取出來,則很多故障就能避免。這里涉及SQL寫法的規范。
規范不僅重要,我們更要主動去履行。如果我們能一鍵發現權限不當、數據庫設計不良、SQL寫法糟糕的問題,那規范就容易遵守,而不是停留在嘴上。不過放心,我們的數據庫整體診斷工具,涵蓋了這里大部分的規范檢查。
結論:
不成規矩,無以成方圓,如果能制定一定的規范并進行有效的檢查,系統的性能問題必然會大幅減少。這里有一個好消息,就是這些要點大多都涵蓋進筆者的一鍵獲取數據庫整體信息的腳本中了。
展全書之學習路線
簡而言之,小王的悲催故事千言萬語化作如下一張學習路線圖。限于篇幅,關于流程規劃就不在書中詳細說明了,我們會將其融進發現問題的整體優化模塊中,并寫成代碼的形式。
內容簡介:

有人就有江湖,有江湖就有IT系統,有IT系統就有數據庫,有數據庫就有SQL,SQL應用可一字概括:“廣”。加之其簡單易學,SQL實現也可一字概括:“樂”。然而,SQL雖然實現簡單可樂,卻極易引發性能問題,此時廣大SQL使用人員可要“愁”就一個字,心碎無數次了。 緣何有性能問題?原因也一字概括:“量”。當系統數據量、并發訪問量上去后,不良SQL就會拖跨了整個系統,我們甚至找不出哪些SQL影響了系統。即便找到也不知如何動手優化。此時的心情也可以一字概括:“懵”。現在本書開始帶你拋除煩惱,走進優化的可樂世界了!首先教你SQL整體優化、快速優化實施、如何讀懂執行計劃、如何左右執行計劃這四大必殺招。整這些干嘛呢?答案是,傳授一個先整體后局部的宏觀解決思路,走進“道”的世界。接下來帶領大家飛翔在“術”天空。教你體系結構、邏輯結構、表設計、索引設計、表連接這五大要領。這么多套路,這又是要干嘛?別急,這是教你如何解決問題,準確的說,是如何不改寫即完成SQL優化。隨后本書指引大家學會等價改寫、過程包優化、高級SQL、分析函數、需求優化這些相關的五大神功。有點頭暈,能否少一點套路?淡定,這還是“術”的范疇,依然是教你如何解決問題,只不過這次是如何改寫SQL完成優化。最后一個章節沒套路了,其中跟隨你多年的錯誤認識是否讓你懷疑人生,其中讓SQL跑的更慢的觀點,是否讓你三觀盡毀?再多一點真誠吧,本書提供掃二維碼輔助學習,是不是心被筆者給暖到了。讀完全書,來,合上書本,閉上眼睛,深呼吸,用心來感受SQL優化的世界。一個字:“爽”!

目錄:

第1章 全局在胸——用工具對SQL整體優化 1
1.1 都有哪些性能工具 1
1.1.1 不同調優場景分析 2
1.1.2 不同場景對應工具 2
1.2 整體性能工具的要點 4
1.2.1 五大性能報表的獲取 5
1.2.2 五大報表關注的要點 10
1.3 案例的分享與交流 18
1.3.1 和并行等待有關的案例 18
1.3.2 和熱塊競爭有關的案例 19
1.3.3 和日志等待有關的案例 20
1.3.4 新疆某系統的前臺優化 20
1.3.5 浙江某系統的調優案例 21
1.4 本章總結延伸與習題 21
1.4.1 總結延伸 21
1.4.2 習題訓練 23
第2章 風馳電掣——有效縮短SQL優化過程 24
2.1 SQL調優時間都去哪兒了 25
2.1.1 不善于批處理頻頻忙交互 25
2.1.2 無法抓住主要矛盾瞎折騰 25
2.1.3 未能明確需求目標白費勁 26
2.1.4 沒有分析操作難度亂調優 26
2.2 如何縮短SQL調優時間 27
2.2.1 先獲取有助調優的數據庫整體信息 27
2.2.2 快速獲取SQL運行臺前信息 27
2.2.3 快速拿到SQL關聯幕后信息 28
2.3 從案例看快速SQL調優 29
2.3.1 獲取數據庫整體的運行情況 29
2.3.2 獲取SQL的各種詳細信息 29
2.4 本章總結延伸與習題 32
2.4.1 總結延伸 32
2.4.2 習題訓練 33
第3章 循規蹈矩——如何讀懂SQL執行計劃 34
3.1 執行計劃分析概述 35
3.1.1 SQL執行計劃是什么 35
3.1.2 統計信息用來做什么 36
3.1.3 數據庫統計信息的收集 37
3.1.4 數據庫的動態采樣 37
3.1.5 獲取執行計劃的方法(6種武器) 40
3.2 讀懂執行計劃的關鍵 48
3.2.1 解釋經典執行計劃方法 49
3.2.2 總結說明 55
3.3 從案例辨別低效SQL 55
3.3.1 從執行計劃讀出效率 56
3.3.2 執行計劃效率總結 60
3.4 本章習題、總結與延伸 60
第4章 運籌帷幄——左右SQL執行計劃妙招 62
4.1 控制執行計劃的方法綜述 63
4.1.1 控制執行計劃的意義 63
4.1.2 控制執行計劃的思路 64
4.2 從案例探索其方法及意義 65
4.2.1 HINT的思路 65
4.2.2 非HINT方式的執行計劃改變 72
4.2.3 執行計劃的固定 100
4.3 本章習題、總結與延伸 102
第5章 且慢,感受體系結構讓SQL飛 103
5.1 體系結構知識 104
5.1.1 組成 104
5.1.2 原理 104
5.1.3 體會 105
5.2 體系與SQL優化 106
5.2.1 與共享池相關 107
5.2.2 數據緩沖相關 111
5.2.3 日志歸檔相關 116
5.3 擴展優化案例 118
5.3.1 與共享池相關 118
5.3.2 數據緩沖相關 122
5.3.3 日志歸檔相關 126
5.4 本章習題、總結與延伸 130
第6章 且慢,體驗邏輯結構讓SQL飛 132
6.1 邏輯結構 132
6.2 體系細節與SQL優化 133
6.2.1 Block 133
6.2.2 Segment與extent 137
6.2.3 Tablespace 139
6.2.4 rowid 139
6.3 相關優化案例分析 140
6.3.1 塊的相關案例 141
6.3.2 段的相關案例 144
6.3.3 表空間的案例 148
6.3.4 rowid 151
6.4 本章習題、總結與延伸 153
第7章 且慢,探尋表的設計讓SQL飛 154
7.1 表設計 154
7.1.1 表的設計 155
7.1.2 其他補充 155
7.2 表設計與SQL優化 156
7.2.1 表的設計 156
7.2.2 其他補充 179
7.3 相關優化案例分析 184
7.3.1 分區表相關案例 185
7.3.2 全局臨時表案例 190
7.3.3 監控異常的表設計 195
7.3.4 表設計優化相關案例總結 199
7.4 本章習題、總結與延伸 199
第8章 且慢,學習索引如何讓SQL飛 200
8.1 索引知識要點概述 201
8.1.1 索引結構的推理 201
8.1.2 索引特性的提煉 204
8.2 索引的SQL優化 206
8.2.1 經典三大特性 207
8.2.2 組合索引選用 217
8.2.3 索引掃描類型的分類與構造 219
8.3 索引相關優化案例 225
8.3.1 三大特性的相關案例 225
8.3.2 組合索引的經典案例 231
8.4 本章習題、總結與延伸 234
第9章 且慢,弄清索引之阻礙讓SQL飛 235
9.1 索引的不足之處 235
9.1.1 索引的各種開銷 236
9.1.2 索引使用失效 236
9.2 感受美好索引另一面 237
9.2.1 索引各種開銷 237
9.2.2 索引使用失效 243
9.2.3 索引取舍控制 246
9.3 從案例看索引各種恨 248
9.3.1 索引的開銷 248
9.3.2 索引去哪兒了 253
9.3.3 索引的取舍 267
9.4 本章習題、總結與延伸 269
第10章 且慢,其他索引應用讓SQL飛 270
10.1 其他索引的總體概述 270
10.1.1 位圖索引 271
10.1.2 函數索引 271
10.1.3 反向鍵索引 272
10.1.4 全文索引 272
10.2 走進其他索引的世界 272
10.2.1 位圖索引 273
10.2.2 函數索引 278
10.2.3 反向鍵索引 282
10.2.4 全文索引 282
10.3 其他索引的相關案例 285
10.3.1 位圖索引 286
10.3.2 函數索引 288
10.3.3 反向鍵索引 297
10.3.4 全文索引 299
10.4 本章習題、總結與延伸 300
第11章 且慢,表連接的秘密讓SQL飛 302
11.1 三大經典表連接概要說明 302
11.2 各類型表連接的知識要點 303
11.2.1 從表的訪問次數探索 304
11.2.2 表驅動順序與性能 308
11.2.3 表連接是否有排序 311
11.2.4 各連接的使用限制 314
11.2.5 三大表連接的特性總結 317
11.3 從案例學表連接優化要點 (三刀三斧四式走天下) 317
11.3.1 一次Nested Loops Join的優化全過程 318
11.3.2 一次Hash Join 的 優化全過程 320
11.3.3 一次 Merge Sort Join 的優化全過程 324
11.3.4 一次統計信息收集不準確引發的NL性能瓶頸 329
11.4 本章習題、總結與延伸 332
第12章 動手,經典等價改寫讓SQL飛 333
12.1 設法減少訪問路徑 333
12.1.1 Case When改造 334
12.1.2 Rownum分頁改寫 337
12.1.3 Hint直接路徑改造 338
12.1.4 只取你所需的列 339
12.1.5 避免或者減少遞歸調用 341
12.1.6 ROWID優化應用 347
12.2 設法避免外因影響 350
12.2.1 Hint改寫確保執行計劃正確 350
12.2.2 避免子查詢的錯誤執行計劃 350
12.2.3 所在環境的資源不足等問題 351
12.3 本章習題、總結與延伸 351
第13章 動手,過程函數優化讓SQL飛 352
13.1 PL/SQL優化重點 353
13.1.1 定義類型的優化 353
13.1.2 PL/SQL的集合優化 355
13.1.3 PL/SQL的游標合并 361
13.1.4 動態SQL 364
13.1.5 使用10046trace 跟蹤PL/SQL 368
13.2 PL/SQL優化其他相關擴展 369
13.2.1 編譯無法成功 369
13.2.2 通用腳本分享 370
13.3 本章習題、總結與延伸 380
第14章 動手,高級寫法應用讓SQL飛 381
14.1 具體SQL調優思路 381
14.1.1 改寫SQL調優 382
14.1.2 不改寫SQL調優 382
14.2 高級SQL介紹與案例 383
14.2.1 GOURP BY的擴展 383
14.2.2 INSERT ALL 389
14.2.3 MERGE 392
14.2.4 WITH子句 402
14.3 本章習題、總結與延伸 404
第15章 動手,分析函數讓SQL飛 406
15.1 高級SQL之分析函數 407
15.1.1 語法概述 407
15.1.2 特別之處 407
15.2 分析函數詳解與案例 409
15.2.1 學習詳解 410
15.2.2 案例分享 417
15.3 本章習題、總結與延伸 432
第16章 動手,把握需求改寫讓SQL飛 433
16.1 考慮需求最小化 434
16.2 千萬弄清SQL改造的等價性 434
16.2.1 看似等價的寫法,其實不等價 435
16.2.2 看似不等價的寫法,其實等價 438
16.3 開發設計應用中的需求 439
16.3.1 界面權限設計優化 439
16.3.2 界面匯總與展現 439
16.3.3 界面實時刷新改良 439
16.3.4 目錄樹菜單的優化 440
16.4 場景選擇的經典案例之誰是Count(*)之王 440
16.4.1 優化過程 440
16.4.2 優化總結 445
16.5 本章習題、總結與延伸 446
第17章 總結與延伸:從勿信訛傳到洞若觀火 447
17.1 SQL優化的各個誤區 447
17.1.1 COUNT(*)與COUNT(列)的傳言 447
17.1.2 談SQL編寫順序之流言蜚語 451
17.1.3 IN與EXISTS之爭 455
17.1.4 總結探討 457
17.2 誤區背后的話題擴展 457
17.2.1 話題擴展之等價與否優先 457
17.2.2 話題擴展之顛覆誤區觀點 458
17.3 全書完,致讀者 461
序: