具体描述
産品特色
編輯推薦
方法意識巧妙融入，腦圖錶格清晰展現；
海量案例完美結閤，綫上綫下拓展延伸。
內容簡介
有人就有江湖，有江湖就有IT係統，有IT係統就有數據庫，有數據庫就有SQL，SQL應用可一字概括：“廣”。加之其簡單易學，SQL實現也可一字概括：“樂”。
然而，SQL雖然實現簡單可樂，卻極易引發性能問題，那時廣大SQL使用人員可要“愁”就一個字，心碎無數次瞭。
緣何有性能問題？原因也一字概括：“量”。當係統數據量、並發訪問量上去後，不良SQL就會拖跨整個係統，我們甚至找不齣哪些SQL影響瞭係統。即便找到也不知如何動手優化。此時的心情也可以一字概括：“懵”。
現在《收獲，不止SQL優化——抓住SQL的本質》開始帶你拋除煩惱，走進優化的可樂世界！
首先教你SQL整體優化、快速優化實施、如何讀懂執行計劃、如何左右執行計劃這四大必殺招。整這些乾嘛呢？答案是，傳授一個先整體後局部的宏觀解決思路，走進“道”的世界。
接下來帶領大傢飛翔在“術”的天空。教你體係結構、邏輯結構、錶設計、索引設計、錶連接這五大要領。這麼多套路，這又是要乾嘛？彆急，這是教你如何解決問題，準確地說，是如何不改寫即完成SQL優化。
隨後《收獲，不止SQL優化——抓住SQL的本質》指引大傢學會等價改寫、過程包優化、高級SQL、分析函數、需求優化這些相關的五大神功。有點頭暈，能否少一點套路？淡定，這還是“術”的範疇，依然是教你如何解決問題，隻不過這次是如何改寫SQL完成優化。
最後一個章節沒套路瞭，其中跟隨你多年的錯誤認識是否讓你懷疑人生，其中讓SQL跑得更慢的觀點，是否讓你三觀盡毀？
再多一點真誠吧，《收獲，不止SQL優化——抓住SQL的本質》提供掃二維碼輔助學習，是不是心被筆者給暖到瞭？
讀完全書，來，閤上書本，閉上眼睛，深呼吸，用心來感受SQL優化的世界。
一個字：“爽”！
作者簡介
梁敬彬，福富研究院副理事長、公司四星級內訓師。不僅是公司特級專傢也是國內一綫知名數據庫專傢，其個人及團隊在數據庫優化和培訓領域有著豐富的經驗、過硬的質量和良好的口碑。多次應邀擔任國內外數據庫大會的演講嘉賓，在業界有著廣泛的影響力。著有多本暢銷數據庫技術書籍，其代錶作《收獲，不止Oracle》已成為數據庫領域有口皆碑的經典書籍，《收獲，不止SQL優化》即將開創一個新的裏程碑。
梁敬弘，清華大學計算機係博士畢業，在計算機領域和金融領域皆有建樹，擁有多項計算機相關核心專利技術的同時，還擁有金融行業的CFP等高級認證。現就職於華夏銀行總行。
精彩書評
眾所周知，數據庫應用是IT係統極其關鍵的核心組成部分，而SQL是數據庫僅有的交互語言，SQL語句實現難度不大， 但是SQL語句優化卻比較復雜，需要有人引路，不過這次有瞭梁老師，廣大讀者有福瞭
梁敬彬先生曾參與的大作《劍破冰山——Oracle開發藝術》一書，直至今日，部分內容在行業裏還發揮著重要影響。梁先生的《收獲不止Oracle》，用生動的故事形式敘述復雜技術，開創數據庫技術書籍故事化寫作的先河。梁先生技術功底和文字功底同樣深厚，更重要的是，具有作為講師的那種縝密、體係化的思維方式，以及對讀者心思的透視力。
此次梁先生的新書更讓我吃驚，整本書的17個章節結閤實戰案例，完全被融入到一套完整的方法論中，脈絡極其清晰，這是一本有著高度思想性的書，構思思路讓人嘆為觀止。這是一本值得嚮行業推介的優秀技術書籍！
黃誌洪（tigerfish）
煉數成金創始人
SQL優化並不簡單，做好SQL優化需要掌握數據庫體係結構、錶和索引設計、高效SQL寫法、高級SQL語法、多種優化工具等知識，甚至還得分析業務特點，以及瞭解優化器的缺點。
隻有建立SQL優化方法論體係，纔能夠迅速找到適閤的方法來優化SQL，從而解決由SQL引發的性能問題。
在這本書裏，梁兄全方位詳解瞭SQL性能優化之道，相信讀者定會受益良多！
丁俊（dingjun123）
ITPUB Oracle開發版資深版主
《劍破冰山——Oracle開發藝術》副主編
繼上一本《收獲，不止Oracle》書後，由梁敬彬、梁敬弘兄弟閤著的《收獲，不止SQL優化》再次問世瞭。感慨兩位兄弟在技術之路上孜孜不倦的追求和無私的分享。
梁敬弘是我的學生，學業專精，為人善良熱心，是一個非常不錯的小夥子。哥哥則精於實戰，善於總結，在業內是一個極為知名的數據庫專傢。兩位兄弟聯手完成的新書必然是數據庫領域的精品，值得大傢去學習和體會。在此，預祝本書的齣版獲得成功，同時也祝兄弟二人在事業上取得更大的成就。
黃連生
清華大學計算機係教授，博士生導師
據我所知，兩兄弟閤著的《收獲，不止Oracle》口碑極好，創造瞭2個月內3次印刷的銷量佳績，滿意率在大型電商網站達到瞭99%以上，獲得瞭巨大的成功。身邊很多清華的學弟學妹們也都購買瞭此書。我作為作者的老師、摯友、大哥，為他們高興，得知他們要再次齣新書，我更是為他們感到驕傲！
翻閱《收獲，不止SQL優化》，我發現這確實是一本與眾不同的書：清晰的結構、形象的比喻、經典的案例、生動的故事讓復雜枯燥的知識瞬間變得簡單有趣起來，更難得的還可以掃描二維碼導入綫上延伸學習，這種責任感讓人贊嘆不已。我堅信，以敬彬的博學多纔和敬弘的紮實嚴謹，這本新書將會成為數據庫書籍的再一個經典傳奇！
王道順
清華大學計算機係教授，博士生導師
《收獲，不止SQL優化》是市麵上我讀到的優秀的一本SQL優化書籍，猶如左右互搏之術，左手原理，右手實戰，左右開弓，原理中有實戰，實戰中有原理，把原理和實戰融為一體。本書的精妙之處在於作者的優化思想，一招緻勝。
本書適閤於IT開發者、DBA、應用運維人員、IT愛好者、計算機專業學生，強烈推薦！
郭一軍(guoyjoe)
尖峰在綫教育創始人，浙江象行數據技術有限公司CEO
我對梁敬彬先生的第1感覺是勤奮。作為一雙兒女的父親，在業餘時間還能獨立完成兩本著作，這本身就需要付齣巨大的勞動。
我對梁先生的第二感覺是有為。集軟件技術專傢、培訓講師、圍棋業餘5段於一身，這充分體現瞭他的纔智。
我對梁先生的第三感覺是親和。我們從他的著作、他發錶的文章，以及他的演講都能體會到，“循循善誘、誨人不倦”這8個字。
這本《收獲，不止SQL優化》，你從章節編排設計就能感受到梁先生的用心，書中的主題也正是數據庫開發從業人員在工作學習中必然會遇到的。數據庫開發博大精深，這本作者從他十多年的成功經驗總結歸納齣的指南，指引我們嚮正確的方嚮前進，少走彎路，健康成長。
盧濤
ITPUB Oracle開發版資深版主
係統分析師
早和梁敬彬先生認識是由於我們長期同在福建省內耕作Oracle並且一起經常被叫作“老師”。熟來熟往，因此瞭解敬彬演繹技術的風格是這樣的：從讀者的角度齣發，在類似小品的故事情節中生活化地展示原先看似復雜的技術。這種風格太好瞭，尤其是用在深入演繹SQL優化這一項他的專長之上。讀過書稿之後，我不禁拍案叫絕。像這樣去傳授SQL知識，去展現實踐，能讓“開捲有益”這四個字實至名歸。
長久以來中國東南地區Oracle技術交流討論的氣氛都不夠濃鬱。為瞭改變本地Oracle社區的現狀，近期非常有幸我能和他一起作為SouthEast China Oracle Users Group（SECOUG）的發起人協力去建設我們自己的本地Oracle社區。在大量的現場技術培訓和技術支持中，我們發現，中國東南地區其實不乏Oracle技術熱愛者，隻是缺乏像用戶組這樣的分享平颱和分享平颱上的有益讀物。尤其是涉及比較復雜的SQL優化項目時，我們的Oracle技術熱愛者們需要有人去交流。敬彬的這本《收獲，不止SQL優化》會成為這方麵傑齣的技術交流媒介，更能幫助SQL優化工作者們在個人技術生涯中因為閱讀此書而有收獲進而變得更為成熟。這本書也會成為SECOUG社區分享的重要讀物。
唐波
中國科學院Oracle EBS優秀技術顧問，福建省知名Oracle WDP講師
中國東南Oracle用戶組SECOUG聯閤發起人，“DBA+社群”聯閤發起人
敬彬兄再次齣書，依然是腦圖邏輯為先，用語通俗易懂，細節深入淺齣。我仔細拜讀瞭第1、2、17章，敬彬兄不僅將SQL優化需要使用的工具做瞭全麵詳實的介紹，更結閤他在不同行業的實際案例，用詼諧筆法娓娓道來。強烈推薦給還在優化之路上奮鬥的DBA、開發人員們，你定會如書名所言，《收獲，不止SQL優化》！
楊誌洪
“DBA+社群”發起人，新炬網絡首席布道師，Oracle ACE，《Oracle核心技術》譯者
與吾兄敬彬相識九載，於劍破冰山始於交心，著述之道甚謹，曾有幸聆聽吾兄傳道，深入淺齣，高屋建瓴，旁徵博引，傢事國事天下事信手拈來，堂上氣氛甚悅，無他“樂”。
樂乃人與生俱來之追求，倘若沒有樂，也就喪失瞭努力的動力。
當然入門之際，首先會“愁”和“懵”。Oracle發展至今已40年，曆經若乾版本，並得以在大數據、雲計算和去IOE的大勢之下屹立不倒，得益於Oracle自身體係架構的嚴謹和不斷完善，洋洋灑灑數十萬頁官方文檔，即使一輩子也未必能窮就。敬彬之特長就在於化繁就簡，由道入術，輕鬆愉悅中掌握SQL優化之技能，一個字“爽”。
弟不纔，混跡於各大IT論壇，嘗聞“術業有專攻”，予則一塌糊塗，得濛寫薦言，不慎惶恐。
王保強
某移動公司首席架構師，IT暢銷書作者
敬彬的新作《收獲，不止SQL優化》的目標非常聚焦。和某些同類書籍噠噠噠地掃射不同，它是以精準狙擊的方式直接鎖定數據庫領域的難點和痛點，即“SQL優化”這個話題，寜小不貪大，求透不求全。
難能可貴的是，本書並沒有多少高深莫測的理論，內容非常接地氣，屬於即學即用、一用見效的類型。那是因為，書裏所有智慧都是從作者和他的同事們實踐中萃取並在實踐中得到反復驗證的，所有代碼都是兩位作者一行一行親自敲齣來的，大多數的案例、故事源自真實的工作場景，可以找到事件的原型。
這本書在易學、易用方麵，下瞭很多苦功。但凡有點SQL基礎的人，看這本書一定不費勁。仿佛有一位優秀的導遊，拿著一張詳盡的地圖，手把手牽著你一路逛過去，你壓根不用擔心自己迷路。在此預祝讀者朋友讀書讀人，見仁見智，受益多多！
王法鬆
企友谘詢CEO，知識管理專傢，知名課程開發師
和敬彬的第1次相識，是源於2015年福建IT培訓聯盟的成立，福富大學校長陳明先生第1個就嚮我推薦瞭敬彬。敬彬給我的第1印象是非常謙虛，他一直強調自己並不是什麼大師，隻是比彆人多瞭一些工作總結，把總結編輯成書籍而已，在我翻看他的第1本數據庫專著《收獲，不止Oracle》時，便被他獨到的寫書風格所吸引，在業界能乾會說的工程師難尋，能乾會說還能寫得一本好書的技術專傢更是鳳毛麟角，他無疑是後者。
敬彬讓我欣賞的另一點是感恩、開放、共享的個性和理念，每當他有機會分享自己的成長經曆時，總是用各種方式真誠流露齣感恩之情，如今他正以自己的努力和付齣迴報這個社會。福建IT培訓聯盟成立之初，他開放分享的理念感染瞭一群懷有技術夢想的年輕人投身到聯盟的公益服務。他專精數據庫技術，點滴成河，匯聚成海，孜孜不倦，匠心可見，《收獲，不止SQL優化》一書是福建IT培訓聯盟的優秀代錶和驕傲。
黃美龍
福建IT培訓聯盟創始人，福州市軟件行業協會副秘書長
目錄
第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 使用10046 trace跟蹤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
前言/序言
序
這是自上一本《收獲，不止Oracle》一書後，我第二次為作者寫序，我知道這又是一本極不尋常的書。
果然，初翻開此書，就給我帶來瞭驚喜。作者將全書脈絡展現得非常清晰，先在前言中通過小故事梳理齣SQL優化的方法論，接下來將各SQL優化的知識點融入到方法論中，形成瞭全書目錄，從而讓讀者明白為什麼要講解這些知識，學瞭這些知識對優化有什麼幫助。更讓人稱道的是，這個目錄是以一個生動有趣的足跡圖展現在讀者麵前的，不落俗套的同時給人一種視覺上的驚艷感。這是誰的足跡，分明是你自己的足跡！於是，一種強烈的代入感油然而生，來，邁開雙腿，學習著，思考著，奔跑著！
足跡所到之處，感動如影隨形，隻因案例無數。我看到瞭作者十多年如一日在工作的荊棘之路中勇往直前的精神，看到瞭作者在攻堅剋難後的沉思總結，看到瞭作者作為感動福富十大人物的一種堅持的精神！更難得的是，這些實戰案例背後密布的代碼不但沒讓我迷糊，反倒讓我覺得非常親切，因為本書為每個章節的案例都進行瞭詳細的分類和匯總，讓人一目瞭然。
翻開此書，作者極佳的文字錶現能力和技術實力立刻躍然紙上，讀者一定會感嘆作者怎麼具備將晦澀難懂的技術書寫得如此清新脫俗的能力！不過我卻一點都不感到意外，始終是抱著一種驗證的心態來閱讀，其中的原因來自於他在公司的雙重身份。梁敬彬是福富特級專傢，又是公司四星級內訓師，前者的榮譽顯示瞭IT人的輝煌技術成就，後者的勛章證明瞭老師的傑齣教學能力，兩者一完美結閤，書中再多的驚喜也不會使你感到意外瞭。我看到IT企業中有很多技術牛人由於在錶達溝通交流方麵的欠缺，在傳幫帶方麵做得不夠好；也看到很多技術人員具備良好的溝通能力卻苦於技術不過硬而無法與人深入交流。作者在這方麵給我們廣大IT技術人員樹立瞭一個很好的榜樣，會打硬仗還要會帶兵。據統計每年接受梁敬彬培訓的福富技術人員多達400人，加上他每年在公司以外的演講和技術分享，梁老師可謂桃李滿天下，給梁老師點個大大的贊！
隨著對此書的進一步瞭解，我知道作者邀請瞭業界許多專傢對此書進行完善、美化、審核。至此，我又讀齣瞭一種精神，叫“團隊精神”，此書正是團隊協作的結晶！作者把工作中的團隊精神帶入書籍編寫中，值得稱道。我在感嘆此書的不同凡響之餘，更感慨團隊的無窮力量！
此書必將成為IT書籍的又一個經典傳奇，我相信廣大讀者在翻閱此書時，除瞭可以學到精妙的SQL優化實用技術外，還可以從無數案例中感受到什麼叫激情、震撼；從方法論總結上理解什麼叫升華、用心；從各種梳理的錶格和思維導圖中體會什麼叫清晰、極緻；從書的精妙視覺設計中領悟什麼叫求道、協作。我想說的是，從菜鳥到SQL大師其實不易，真正的大師不止是技術上精湛，還需要一種精神。這種精神，還請你在閱讀本書中感悟吧！
福富軟件公司副董事長 楊林
匠心獨運 獨樹一幟
——與梁敬彬先生序
在拿到敬彬新書的稿件時，我的腦海第一時間呈現齣來的就是這八個字：匠心獨運，獨樹一幟。
技術書籍的寫作也是一個創作過程，平庸者韆篇一律，卓越者自齣機抒。
寫作一本韆篇一律的書很容易，而要想自齣機抒，形成自己的風格，並且為讀者認可，則是難上加難。而敬彬的係列作品，已經形成瞭自己獨特的風格，並且為廣大技術愛好者們所喜愛，這不獨是匠心所在，更是隱現宗師風範。
如作者所說，有數據庫就有SQL，而SQL又因其靈活、復雜，而讓眾多應用係統飽受性能之苦。我一直認為，在開發環節提高SQL質量纔是數據庫優化的治本良方，SQL審核也是DevOps理念在數據庫領域的最佳落地點，雲和恩墨也在此保持持續的關注並研發瞭産品。敬彬的新書從SQL入手，以其獨特的故事演繹法，讓SQL優化成為瞭一種趣味，書中還通過實例打破瞭以訛傳訛的種種法則，讓讀者獲得思想上的自由。
這是一本活的書，活躍的思想，活潑的行文，活動的二維碼，活靈活現的音視頻，互聯網時代，原來書還可以這樣寫。
快點來一起體驗吧！
蓋國強
雲和恩墨創始人，Oracle ACE總監，ACOUG主席
緻謝
我首先要感謝福富軟件公司，因為這本書的原型，正是公司的認證資格課程《基於案例學SQL優化》。公司福富大學專程請來專業的企業內訓專傢為福富內訓師們做內訓課程的培訓和完善，最終這門課程有幸成為我們公司年度三門精品課程之首。這期間福富研究院的專傢們對本課程進行瞭大量的評審，並提齣瞭各種寶貴的意見。感謝福富公司！感謝福富大學和福富研究院！
我要感謝我們項目組團隊的成員，沒有黃鐧、榮誌等公司傑齣的技術專傢和我並肩作戰，我也沒有精力寫完這本書。我要感謝姚建藝、鄭清泉、鄭超群等，他們為我們團隊的工作提供瞭最有力的幫助。要特彆感謝我們的楊總，她一如既往的支持、她熱情洋溢的《序》讓我感動不已！
我要感謝我弟梁敬弘在本書內容上傾注精力。感謝林舒楠、張鳳為本書在視覺設計上提供的幫助。感謝謝恒忠在綫上拓展方麵提供的幫助。謝謝你們的參與！
此外，我要感謝蘇旭暉、盧濤、丁俊等這幾位業內知名的數據庫專傢對本書的審核校驗，感謝博文視點在齣版方麵的專業性指導意見。感謝大傢的幫助！
最後，我要感謝我親愛的傢人，謝謝你們的支持！
梁敬彬
2017年4月
前言與意識：從優化方法到全書脈絡
嘆IT之一入深似海
傳說：一入IT深似海，從此菜鳥淚成河。
老師，搞IT真有傳說中的這麼慘嗎，那我從此要珍愛生命、遠離IT瞭。
我們慢慢聊吧。話說這時代啊，應該是最好的時代瞭。知識的獲取相當便利，基本上沒有什麼知識點是搜索引擎搜不到的；此外，現在的技術書籍、教學視頻也非常豐富。除瞭自學手段外，我們甚至還可以在論壇上提問，或者參加各種綫上和綫下的培訓。當今時代，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寫法糟糕的問題，那規範就容易遵守，而不是停留在嘴上。不過放心，我們的數據庫整體診斷工具，涵蓋瞭這裏大部分的規範檢查。
結論：不成規矩，無以成方圓，如果能製定一定的規範並進行有效的檢查，係統的性能問題必然會大幅減少。這裏有一個好消息，就是這些要點大多都涵蓋進筆者的一鍵獲取數據庫整體信息的腳本中瞭。
用户评价
恍恍惚惚恍恍惚惚哈哈
评分全书围绕oracle讲的，oracle数据库优化，并不通用，虽然内容可以
评分还可以，很好用，正是我所需要的
评分还没时间看，先留着
评分没用，说真的
评分质量好，发货速度快，客服也有耐心！
评分都是做这个生意发财我们一样
评分梁老师又一大作，收获永远不止
评分还可以，很好用，正是我所需要的
相关图书
本站所有內容均為互聯網搜索引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 tushu.tinynews.org All Rights Reserved. 求知書站 版权所有