圖書信息
書名：海量資料庫解決方案
作者：[韓]李華植著 鄭保衛 蓋國強 譯
ISBN：978-7-121-11883-8
出版日期：2011年1月
定價：69.00元
開本：16開
頁碼：460頁
宣傳語
涵蓋資料庫專家最新核心技術的rdbMS經典書籍
包含了將代碼縮減為原來的1/10倍而速度提高至原來10倍的先進方法。
揭開了關係資料庫的真面目，展示了截至目前為止未能被靈活使用的新技術。
內 容 簡 介
本書將整體內容分為兩部分，在第1部分中以影響數據讀取效率的所有要素為類別，對其各自的概念、原理、特徵、套用準則，以及表的結構特徵、多樣化的索引類型、最佳化器的內部作用、最佳化器為各種結果制定的執行計畫予以詳細說明，並以對最佳化器的正確理解為基礎，提出對執行計畫和執行速度產生最大影響的索引構建戰略方案；在第2部分中主要介紹提高數據讀取效率的具體戰略方案，在這部分中介紹與數據讀取效率相關的局部範圍掃描的原理和具體套用方法，以及對被認為是提高資料庫使用效率基礎的表連線的所有類型予以詳細說明。
《海量資料庫解決方案》系列叢書深受廣大讀者的喜愛已經長達10年之久，在被譽為“聖經”的同時，它已經變成了資料庫用戶不可或缺的必讀書籍。作者竭力探求能夠讓IT工作者在實際工作中輕鬆套用並掌控的巧妙方法，提供事半功倍的海量資料庫解決之道。
本書適合資料庫開發人員和資料庫管理員等閱讀。
編輯推薦
《海量資料庫解決方案》：
涵蓋資料庫專家最新核心技術的RDBMS經典書籍
包含了將代碼縮減為原來的1/10而速度提高至原來10倍的先進方法。
揭開了關係資料庫的真面目。展示了截至現在未能被靈活使用的新技術。
10億韓元 40萬冊銷售神話
韓國資料庫泰斗李華植先生力作風靡日韓
蓋國強 鄭保衛博士 譯ITPUB資料庫版主張樂奕 崔華 審校
《海量資料庫解決方案》是一本全面反映過去10年迅速發展的商用DBMS最新資料庫套用技術、強化資料庫技術靈活運用原理及系統化具體套用準則的高水平的經典書籍。
《海量資料庫解決方案》曾在韓國和日本同時出版發行。在日本最權威的資料庫專業出版社（株）——翔泳社出版局出版發行《海量資料庫解決方案》的同時，也將韓國先進的資料庫技術傳播到了日本。此次在發行中文版的同時，也希望《海量資料庫解決方案》中所涵蓋的技術能夠對中國的廣大讀者有所幫助。《海量資料庫解決方案》中所涉及的普遍性原理適合於任何DBMS，只要對語法稍加調整便可在所有DBMS中得到有效使用。為了便於讀者對關係資料庫的概念、最佳化器的靈活運用原理、適用於多樣化實際業務中的明確套用準則有一個充分的理解，在《海量資料庫解決方案》中通過舉例對這些內容進行了詳細說明。
作者簡介
作者：（韓國）李華植 譯者：鄭保衛 蓋國強
李華植
代表韓國的資料庫技術先驅
集基於EA(Enterprise Architecture)的數據架構(Data Architecture)
方法論之大成
在韓國最早提出了數據專家顧問的概念
現任EN-CORE CONSULTING總經理及代表顧問
曾在韓國Oracle公司擔任200多家企業的技術顧問
論文：《構建海量數據系統時的RDB Performance問題解決方案》
書籍：《Data Modeling＆Database Design》(1995)
《Oracle Server Tuning}(1995)
《海量資料庫解決方案》(1996)
《海量資料庫解決方案Ⅱ》(1998)
《數據架構解決方案I》(2003)
譯者簡介：
鄭保衛，於韓國國立釜慶大學信息工學系獲得工學博士，現任職於韓國最權威的資料庫公司EN-CORE CONSULTING，併兼任企業研究所研究員及資料庫電子商務研究所主要研究員。研究方向包括數據模型設計、海量資料庫解決方案、數據架構、基於資料庫技術的專家智慧型系統、ITA／EA（Infomation Technology Architecture/Enterprise Architecture）。
蓋國強（網名eygle），Oracle ACE總監，恩墨科技創始人，ITPUB論壇超級版主，遠程DBA服務的倡導者和實踐者，致力於以技術服務客戶。著有《深入解析Orade》、《循序漸進Oracle》、《深入淺出Oracle》等書：從2010年開始，致力於《OracleDBA手記》的撰寫與編輯工作，並與張樂奕共同創立了ACOUG用戶組，在國內推進公益自由的Oracle技術交流活動。張樂奕（網名Kamus），恩墨科技技術總監，Oracle ACE，ITPUB資料庫管理版版主。他曾先後於北京某大型軟體公司、外資電信企業、諮詢公司任首席DBA。後任職於北京甲骨文軟體系統有限公司，高級顧問。他熱切關注Oracle資料庫及其他相關技術，對於Oracle資料庫RAC及高可用解決方案具有豐富的實踐經驗，長於資料庫故障診斷、資料庫性能調優。他還是各類技術會議的熱心分享者，2010年3月創建ACOUG用戶組。
崔華（網名Dbsnake），2004年開始從事DBA工作，在Oracle的安裝、升級、開發、性能調整、故障處理方面有豐富的經驗，對Oracle的體系結構具有深入了解：深入理解Oracle的記憶體結構、物理存儲（各種塊格式）、鎖機制、最佳化機制等：深入了解Oracle的備份恢復機制，熟悉Oracle的各種備份方法，能夠處理各種情況下的複雜數據恢復情況。
崔華也是熱心的技術分享者，多次在ACOUG的活動上與技術愛好者分享技術心得。
作者序言
這已經是第四次為本書寫作者序言了，此時此刻過去20年的生活如同電影般在我的腦海里一一掠過。當我最初決定步入IT領域時就為自己立下了誓言，時至今日回想起多年走過的歷程，其間充滿了艱辛，也正是這無數的艱辛讓我最終體驗了收穫的愉悅。
回望這20多年的足跡，我一直努力用新的視角去觀察他人所忽視的領域，嘗試用嶄新的思維和充滿創意的雙手去耕耘。儘管如此，也仍然無法緊跟IT技術飛快的發展步伐。我為實現理想而終日不停前行的腳步，雖然忙碌但卻無限滿足。
眾所周知，能夠加工成寶石的原石比比皆是，一分耕耘，一分收穫，每當我們初次接觸某個新的東西時都會或多或少有些緊張。因此從這一層面來看，資料庫散發著無窮的魅力，它如同淵博精深的智者般質樸，總是以真實、坦誠的心去面對每一位學習和研究它的人。
在過去並不短暫的歲月里我一直深信資料庫的骨骼就是“數據”，並為這一理論的發展不斷努力，吸收同仁們分享的經驗而持續奮鬥。為了打破始終在理論表面徘徊的固有模式而不斷尋求新的嘗試，並試圖探求能夠讓IT工作者在實際工作中輕鬆套用並掌控的巧妙方法。
這種巧妙方法不能是只通過經驗和試驗才能獲得的，它必須是利用日常常識就可以理解說明的方法。有這么一句話“會者不難，難者不會”，如果能夠把一些複雜的理論與通俗淺顯的常識相結合，那么不僅有利於人們的理解，更有利於人們在合適的情況下加以靈活運用。相反，有這么一句話“一知半解以為是”，意思是指那些只觀其表不觀其里就加以相信的人。
很多程式設計師只忠實地相信自己的經驗，當問及為何如此時，大部分人的答案都是“因為我那樣做過”或“那樣比較好”。10種類型的原理可以組合出10的階乘（3 628 800）種現象，那么100種類型的原理所能夠表現出來的現象數可以認為是一個天文數字。
如若僅憑經驗去思考問題，無論怎么努力，最終也只能獲得其中一部分的原理而已。然而，事實上我們是完全有能力深刻地理解這100種原理的。但如果不試圖進行深刻鑽研而只停留在表面，最終只能是一無所獲。寶石是不會被輕易發現的，只有憑藉最大的努力去尋找方能找到。
在不知不覺中當我們遇到了從表面上看無法解決的複雜問題時，會出現兩種人：其一，是堅持不懈、徹夜不休也要尋找到最佳解決辦法的人，這種人通過不懈的努力最終能夠獲得什麼呢？事實上隨著歲月的流逝，他們終將成為眾人皆知的專家；其二，是認為過於煩瑣，直接予以放棄的人，這種人只會讓自己的血汗變成廉價的廢棄物。
可以自豪地說“我付出了常人所無法想像的艱辛”，為了尋求完美的真理捨棄了很多常人的生活。在沒有釣到魚時釣魚人也許會為此而耿耿於懷，但在我看來問題的關鍵在於沒有尋找到有效的釣魚方法。如果釣魚人能夠充分理解我的想法，並甘願為了改變自己的固有觀念而付出較大努力，儘管他也可能會為此而花費大量的時間和心血，但堅信他一定能夠獲得別人所無法獲得的成果。如果他研究出了別人所無法研究出的釣魚方法，那么從此就再也不用為釣不到魚而擔心了。
各位讀者在工作的同時究竟是否一直在使用一種平凡的方法呢？還是為了解決明天必須要完成的任務而臨時抱佛腳呢？現在該到結束這種惡性循環的時候了。應用程式其實就是處理數據的手段而已，它需要緊跟流行的步伐，如不及時進行更新，在不經意之間就已經落伍了。
然而數據和資料庫並非如此，不論歲月如何流失，我們積攢起來的“內功”是不會消失的。如果能對其原理有一個深刻的理解，那么不論何時何地都能夠隨心所欲地釣到很多魚。隨著資料庫技術的發展進步，能夠精確執行指令的DBMS與日俱增，隨著對DBMS套用能力的不同所獲得的性能差異使我們從技術中獲得滿足感。
不知不覺中《海量資料庫解決方案》系列叢書深受廣大讀者的喜愛已經長達10年之久，在被譽為“聖經”的同時，它已經變成了資料庫用戶不可或缺的必讀書籍。截至今日，本書依舊深受廣大讀者的喜愛。
IT領域技術10年的發展狀況與其他領域100年的發展狀況相當, 在資料庫的發展歷程中，有一些技術和原理被不斷更新，有一些技術和原理被直接替代，也有一些技術和原理始終被維持使用。其中能夠被持續使用而沒有被改進的，說明它們是完美的，是適應性非常強的。
然而，我並沒能及時將資料庫所提供的新功能的真正含義和特性，及其在實際工作中的靈活運用方法和準則介紹給各位讀者，借這次機會向各位忠實的讀者表示深深的歉意。我知道很多讀者對這本新書寄予了厚望， 相信通過我的努力能夠讓各位讀者如願以償。
事實上，本人在此期間為了研究數據架構（Data Architecture）的相關理論花費了大量的時間和精力，因為我認為數據架構的重要性和根本性主要體現在它是蒐集和管理數據體系的理論，它的目的在於以資料庫技術為基礎，構建更加深邃、全面的數據體系。現在，有很多用戶開始對數據構建的相關理論感興趣，並且一些用戶還組織了專門的學習小組，我為此而感到非常欣慰。
隨著信息化進程的不斷加快，利用資料庫所要管理的數據不僅會顯著增多，而且也會變得非常複雜，由此而引發的數據合併、標準化、數據質量等方面的問題也已經到了不得不解決的境地了，實際上可以說是迫在眉睫。因此，構建以監督數據構架是否按照要求構建、完善對數據進行有效控制的元數據系統，已經成了我們所必須完成的迫切任務。
幸運的是，很多開發人員和管理人員都對數據構架注入了極大的關心，韓國政府為此專門設定了數據構架資格考試，也正是由於國家和各位IT領域從業者的努力才使得數據構架有了今天的良好發展形勢。為了使其得到進一步的發展，我們為此而研究出了更為體系化的理論方法，出版了高質量的書籍，設定了高標準的培訓課程，構建出了將數據構架解決方案和相關組件相結合的元數據系統。
然而，在我為了推進數據構架的發展而付出大量時間和精力的同時，並沒有放棄對資料庫的研究。在此期間，我不僅連續不斷地向很多用戶提供資料庫的諮詢工作，而且也在不斷地研究著新出現的技術。雖然我並沒有公開地出版新書，但是卻編寫了大量的研究材料，並將其中相當大一部分在公司韓國資料庫振興院的主頁上公開發表。儘管如此，現在對資料庫的深刻研究，並將這些材料系統化的工作已經迫在眉睫了。
經過一年的晝夜工作終於完成了本書，並為了在本書中涵蓋所有DBMS的“最低公倍數”而付出了很大的努力。雖然在各個DBMS之間多少都有一些差異，但是如果從原理和靈活運用準則的角度來看，它們之間其實並沒有太大的差異。如若對所有DBMS的功能進行詳細說明，反倒不利於各位讀者的理解，所以在本書中以Oracle為基準進行說明的部分比較多。
儘管在本書中所使用的描述方法和命令語言主要以Oracle為基準，但所說明的原理和概念適用於所有的DBMS，這就像儘管每一個照相機的具體操作方法都有所不同，但從拍攝照片的角度來看卻並沒有太大的差異一樣。為了幫助各位讀者更好地理解和套用本書中所介紹的原理和方法，介紹其被套用在各個不同DBMS中的相關書籍在不久的將來將呈現給各位讀者。
本書將整體內容分為兩個部分，在第1部分中以影響數據讀取效率的所有要素為類別，對其各自的概念、原理、 特徵、套用準則，以及表的結構特徵、多樣化的索引類型、最佳化器的內部作用、最佳化器為各種結果制定的執行計畫予以詳細說明，並以對最佳化器的正確理解為基礎，提出了對執行計畫和執行速度產生最大影響的索引構建戰略方案。
在第2部分中主要介紹提高數據讀取效率的具體戰略方案。在這部分中，介紹與數據讀取效率相關的局部範圍掃描的原理和具體套用方法，以及對被認為是提高資料庫使用效率基礎的表連線的所有類型予以詳細說明。
在第1部分的第1章中，主要對資料庫在存儲數據時所使用的基本存儲結構進行詳細說明。就像人類無法生活在水中，魚類無法生活在陸地一樣，結構上的特徵對很多方面都有著根本性、決定性的影響。儘管不同的DBMS所使用的術語有所不同，但是當我們依據其本質進行分類時就會發現所有表現出來的形式都屬於同一種類型。
在第1部分的第2章中，主要對最佳化器制定執行計畫影響最大的所有索引類型進行詳細說明。在此所涉及的索引類型有被廣泛使用的最一般的B-Tree索引、在海量數據處理或數據倉庫中能夠獲得較好效果的點陣圖索引、基於虛擬列所創建的多樣化的用戶自定義函式索引等。
在第1部分的第3章中，主要對最佳化器進行深刻剖析。在此不僅介紹最佳化器在實現最最佳化操作時所執行的內部執行步驟，還對作為資料庫處理數據步驟的執行計畫的各種類型進行了分類說明。如果各位讀者能夠對各個具體的執行單位有一個很好的理解，那么仍然能夠對將其組合在一起的整體執行計畫有一個很好的理解。另外，為了引導最佳化器按照我們所期望的方式制定執行計畫，又對各種類型的提示（Hint）進行了說明。
在第1部分的第4章中，非常具體地提出了對制定最最佳化執行計畫有著非常大影響的索引構建戰略方案。最佳化器並不能開闢出新的讀取路徑，而只能在現有的讀取路徑中選擇出比較有效的路徑。因為按照本書中所提出的索引構建戰略方案所構建出的索引能夠改變現有的讀取路徑，所以如果沒有依據此方案來構建戰略性的索引，那么數據的讀取效率必然會在很大程度上受到影響。
在第2部分的第5章中，以對執行計畫的正確理解為基礎，通過具體事例，對唯讀取了部分數據就能獲得結果的秘訣——局部範圍掃描的原理和多樣化的套用類型進行了詳細說明。在這裡從一個新的高度對前面所介紹的方法進行了擴充說明。最後對在各種比較流行的留言板中實現局部範圍掃描的方法進行了詳細說明。
在第2部分的第6章中，對表連線的所有類型進行了詳細說明。在這裡對作為傳統型的表連線方式——嵌套循環連線和排序合併連線，以及能夠有效實現海量數據連線目的的哈希連接的相關原理進行了徹底剖析，並提出了多種靈活運用準則。另外，又對以多樣化類型出現的半連線和在數據倉庫中必須要使用的星型連線，以及星變形連線進行了詳細說明。最後附加性地提出了點陣圖連線索引的基本概念和靈活運用方法。
在這裡向各位讀者鄭重承諾，我將在儘可能短的時間內完成其他兩本系列書籍的編寫工作。由於我經常在讀者所期待的時間內未能出版約定的書籍，也許各位讀者對我如期完成這兩本書並不抱太大的希望，所以在這裡希望各位讀者能夠諒解。我在管理自己企業的同時，既要研究新的技術，又要提供解決方案和編寫書籍，時間的不足真的讓我窘迫和無奈。
由於這兩本系列書籍會同時在國外出版發行，所以不論我被多少瑣事所困擾，都必須在約定的時間內完成編寫工作。因此，這次我可以在這裡向各位讀者鄭重承諾，在本書出版發行後我會以最快的速度完成這兩本系列書籍的編寫工作。
只憑藉對方法的理解是無法征服數據世界的，即使將本書已經閱讀了數十遍也只不過是停留在對其表層內容的理解上而已。所以希望各位讀者能夠對自己提出更高的要求，不要停留在對表層內容的理解上，而是以對本書中所介紹的所有原理的正確理解為前提，以本書中所提供的案例為參考，在適當的實際案例中加以靈活運用。我希望各位讀者能夠通過自己的努力和奮鬥，發現別人所不能發現的新世界，而不是僅將自己局限於眾人都能夠看到的世界裡。要勇敢地去挑戰自己的極限，走向更大的成功。
2005年12月13日
En-core Consulting
代表諮詢師 李華植
他山之石 可以攻玉
——《海量資料庫解決方案》校訂手記
編輯文案：
如果網際網路也講究人口紅利，那中國無疑擁有得天獨厚的人口基數與網際網路普及速度。隨著用戶及服務規模的急速增長，海量資料庫問題不期而至。然而，這一變遷過程進行得太快，相關從業人員來不及做好充分的技術準備，比如說，找不到任何一本可參考的書籍。
也正緣於此，曾服務過幾乎所有本國一流世界級企業、擁有幾十年從業背景的韓國資料庫泰斗李華植先生的暢銷著作《海量資料庫解決方案》進入我們的視線。在充分了解到該著作在日韓經久不衰的事實，並有請國內知名資料庫圖書作家、技術權威蓋國強老師謹慎評估後，我們有幸將其引入國內，供國內資料庫同行參閱與品評。
國內韓版技術書籍的匱乏，主要是因為同時具備語言與技術能力的人選少之又少。為保證本書得以順利出版，並保持較高水準，特邀原作者創辦之EN-CORE公司的鄭保衛先生進行初譯，蓋國強老師進行深入譯校、中文統籌，張樂奕、崔華兩位資料庫資深專家與蓋國強老師一道對本書進行了全面的技術解讀、轉譯及校訂。
本書的原著者、出版方及參與審譯的同仁，都傾注了頗多心力，只希望本書的出版能在一定程度上填補國內關於海量資料庫技術方面的空白，為日新月異的網際網路產業發展貢獻綿薄之力。實效如何尚不得而知，但請讀者朋友不吝指正。
經過三個月的艱苦努力，我和張樂奕（Kamus）、崔華（Dbsnake）最終完成了《海量資料庫解決方案》的校譯工作。能和兩位好友一起字斟句酌、逐字逐句地將韓國同人的名作校譯引入中國，於我們於書都是一種緣分與機緣，在校訂過程中恩墨科技的羅曉程也協助我們做了大量的文字審閱工作，在此致以深深的謝意。
在各位讀者開始閱讀本書之前，我們將接觸、接受、校譯這本書的感觸與來龍去脈記錄一下，供大家參詳。
Eygle —— 推動技術交流與分享是一件功德
最早接觸到這本書是在2009年，韓國EN-CORE公司的朋友找到我，希望我能夠幫忙審閱並做些推薦，當時我正在新華社進行一個項目實施工作。
我當即表達了自己的幾個觀點：第一，如果是一本好書，我樂於閱讀並做評薦，這是我的榮幸；第二，凡是促進技術交流與分享的事情，我都樂於支持並做出力所能及的工作；第三，我願意義務地去做這樣一件事情。
韓國朋友非常愉快地表達了對我的謝意，並向我介紹了這本書：在韓國資料庫界，該書的作者李華植是教父級的人物，而該書更是聖經般的讀物，有累計幾十萬冊的銷量，讀者不僅僅是資料庫從業人員，各類技術人員都將其奉為經典和必讀。
我相信了他們的說法，並且向韓國同仁表達了敬意。所有堅持不懈、執著於行的人，都值得我們尊敬。而如果能夠促進亞洲數據庫界的一些交流，那也是一件功德。
就這樣我欣然答應了他們的請求，並期待看到這樣一本書的出版。
當我拿到書稿時，一些新的問題出現了，我發現原譯文太注重韓文的語言習慣，對於中國的讀者來說，閱讀起來會非常吃力，甚至會出現難於理解的局面。我建議他們做出進一步的修訂，否則很難傳達出作者的本意。基於雙方的理解，他們誠摯地邀請我來完成這個審校工作，而經過慎重考慮之後，我認為一個人還不夠，我需要一個團隊，張樂奕和崔華成為了我的夥伴，這個團隊通過了他們的考察，就這樣，我們接下了這個比想像的還要艱辛的工作。
從原譯文的傳達，去理解作者的本意，這本就隔了一層，再加上韓文和中文的語言習慣不同，修訂的工作極其艱苦，經常每個小時只能完成兩三頁的校對修正，然後我們三個人還要交叉校訂。這期間的小插曲是，由於張樂奕是日語專業出身，他能夠從該書的日文版借鑑不少東西，互相佐證。
就這樣，三個月的時間轉瞬即逝，我們的工作也已經接近尾聲，我可以說的是，我還從來沒有這么認真、字斟句酌地去讀過一本書，而且是反反覆覆地閱讀，這樣閱讀的一個好處是，我對這本書的理解和領會比任何其他一本書都要多。
書稿在手裡就沒有完美的一刻，我們還在不停地修正，直到出版前的最後一刻。我們真摯地希望能夠有更多的讀者喜歡它。雖然這期間我們已經盡了最大努力，但是仍然不知道讀者會如何評價，所以我一直心懷忐忑。
關於這本書，可以說的是，我從中學到了很多東西，作者的很多理念讓我受益匪淺，這些學到的東西將會指導和影響我以後的學習之路。
首先這本書並不是僅僅寫給資料庫從業人員的，作者期望所有對資料庫感興趣的讀者都可以流暢地閱讀、透徹地理解。所以，作者在本書中通過大量的類比、比喻將艱深的資料庫知識與生活對應起來，使得平時很多不易理解的概念變得淺顯易懂。基於深刻的積累，作者能夠從不同角度對技術進行概括和闡釋，往往有讓人豁然開朗的別樣感覺。比如在講到局部範圍掃描時，作者用排隊等車用戶的順序以及計程車的出發時間進行類比譬喻，精到而淺顯，任何人都可以一目了然地理解後面蘊含的複雜技術原理。這或許就是作者的本意，技術原本就是對完美生活的引申與抽象。
又比如在戰略性索引構建一章，作者提到“只要為各個索引分配合理的任務，即使需要創建大量的索引也應當果斷地作出決定”，為索引指定任務使得索引擬人化地變成了一個工人，有明確任務而不是平時我們茫然地創建索引。作者依據這樣一個思想展開了整章的內容，這也和我們的最佳化思路不謀而合，最佳化到極致的資料庫，我們應當知道哪些SQL查詢會使用到哪些索引，而索引又是為哪些查詢服務的，必須詳盡了解資料庫與套用，才能對套用系統了如指掌、有的放矢。
讀這本書，我們更多的是去理解作者高屋建瓴的資料庫設計與最佳化思想，而不應該拘泥於具體的技術細節，比如作者所說的局部範圍處理、戰略性索引構建等，這些概念更多的是將細節的技術原理上升到生活道理與常規的思考。原本很多複雜的技術設計都是可以源自生活中淺顯的道理，將技術、生活與常規的思考聯繫貫穿起來，在我看來，是作者帶給我們的最大教益。
最初的一句承諾，導致了數月的鍥而不捨，這期間的艱苦也讓我們每個人都有所收穫，當然更大的收穫是我們幾個朋友之間的友誼；感謝作者李華植帶給我們的經典作品；感謝譯者鄭保衛，正是他的初始翻譯才使得本書的中文版得以和廣大讀者見面；感謝博文視點的張春雨，他堅持不懈的溝通與推動促成了本書的最終出版。
願這本書能為大家帶來一些與眾不同的感覺與收穫！
蓋國強
2010年7月22日
Kamus——書讀百遍其義自見
在今年（2010年）一月份的時候，Eygle跟我說有一本韓國IT屆教父級的人物撰寫的在韓國狂賣數十萬冊的資料庫技術書籍，出版社希望引進到中國來。而這本韓文書已經有了初始中文譯本，只是這份中文譯本需要一些更熟悉Oracle資料庫技術的人來進行再次修訂。當第一次聽到這件事情時，我以為那僅僅是校對，對於錯別字的校正；對於技術術語把握的問題，我沒有想到在真正開始著手以後會是如此的困難。
時間過了兩個月，到了今年的3月份，正式拿到書稿，當開始修訂我負責的第3章時，才發現這是一項巨大的工程。並不是說初始翻譯不好，實際上已經很不錯了，技術術語基本上也都準確，但是整段整段的句子讀下來，卻發現讀一遍不明白在說什麼，讀兩遍仍然似懂非懂，讀三遍可能才知道，喔，應該是這個意思。而第3章是占全書比例最大的章節，有一百五十多頁，而即使我全神貫注地去修訂，進度也僅僅能夠達到一個小時兩到三頁。之前我工作的環境是在客廳，前面是電視機，而為了修訂這本書我不得不將工作環境轉移到書房，因為哪怕是一點點聲音的干擾也會讓進度更加緩慢。這是我之前沒有遇到過的情況，我一向自詡可以一心多用，但是修訂這本書我遇到了極大挫折。究其原因，應該是初始翻譯有不少是通篇大量同詞語替換的情況，很多的修飾詞都不符合中文的語言特點，而這些修飾詞極大地干擾了我的閱讀體驗。另外一個重要的因素就是李華植先生在寫作這本書的時候，對於很多他想極力闡述給大家的觀點都輔以了大量的比喻，用計程車、用運動員、用下棋……而這些比喻的生動讓閱讀者會情不自禁地將自己帶入這個環境，去仔細琢磨這個比喻的後面想表達的真實含義。
為了能夠更準確地理解李華植先生原文的意思，我甚至找來了本書的日文譯本出版物（我大學本科學了四年的日語），在我實在不明白原中文譯本的含義時，我會去對照日文是如何翻譯這段的。有趣的是，通常這很有效果，我甚至根據日文譯本在中文譯本中添加了一些文字（也許是原中文譯本遺漏了），以便於讀者能夠更好地理解文章含義。
很令人欣喜的是，在修訂的後期我已經能夠逐漸跟上李華植先生的思維，甚至對於他的比喻已經心有戚戚，修訂的速度也得以提高。更令人欣喜的是，如此字斟句酌地閱讀李華植先生的這本著作，讓我在Oracle資料庫性能最佳化的思想和策略上都學到了很多東西。“書讀百遍其義自見”很能貼切地描述修訂這本書的過程。
我、Eygle和崔華在三個月中交叉修訂，我修訂完的第3章Eygle會再次修訂一遍，然後傳遞給崔華，崔華再閱讀一遍，同樣Eygle修訂完的第4章會傳給我再重新閱讀。我們如此努力，只是希望在最後這本書呈現在大家面前的時候，是一本符合中文閱讀習慣的、不需要再像我們這樣費勁就能夠有所收穫的資料庫技術書籍。這是辛苦的三個月，但同樣是很有意義的三個月。
對於每一位能夠將自己的經驗寫下來分享給讀者的作者，我都深深敬佩。我個人雖然一直沒有這樣的耐性坐下來去真正寫一本書，但是我也一直在努力創造一種樂於分享、收穫快樂的環境，創辦Oracle中國用戶組，每個月舉辦免費的活動，邀請演講者來做技術分享，我一直在努力做自己力所能及的事情。
最後，即使我們如此修訂這本書，一定還會有疏漏的地方，甚至是詞不達意或者難以理解的部分，希望讀者朋友們能夠包容。但是更重要的一點是，在你覺得無法理解的時候，歇一段時間再去讀第二遍、第三遍，要知道在我們修訂的時候也是這樣，“書讀百遍其義自見”。
張樂奕（Kamus）
2010年7月4日
Dbsnake——循序漸進始有成
三個多月的時間一晃就過去了，我們也終於完成了《海量資料庫解決方案》的修訂工作。
當初Kamus打電話找我，問我是否有興趣跟他和Eygle一起去修訂一本韓國書的時候，我幾乎是不假思索地馬上就答應了，當時其實我並不知道要修訂的是什麼書，也不知道具體的工作量會有多少。滿口答應只是因為這是Eygle和Kamus找我——我沒有理由拒絕。
修訂這本書的時候恰逢我跟進的一個項目上線，白天項目的事情已經是忙得焦頭爛額了，修訂的工作只能夠放在晚上做。等到我真正開始修訂的時候，才發現工作量真的是太大了，因為幾乎是一直處於一種字斟句酌的狀態，所以修訂的進度非常緩慢，我常常是一個小時才能修訂兩到三頁。怎么辦？我怎樣才能提高修訂的速度，以至於不耽誤整個團隊的進度？沒有別的辦法，我只能壓縮自己的睡眠時間，於是每個工作日我基本上都是12點左右入睡，早上5點半起床，就這樣堅持了三個多月。
現在回頭想想，我為什麼能夠堅持下來？除了要信守我自己的承諾之外，另外一個很重要的原因就是我對Oracle資料庫太感興趣了，再加上這本書確實是一本難得的好書！我在仔細修訂這本書的過程中已經感覺到了自己的進步，這真的是一件令人非常興奮的事情！
常常有朋友問我如何才能學好Oracle？我這裡想說的是我也不知道該如何才能學好，因為Oracle我也只懂一點點。但是當我看到李華植先生將其20年的資料庫經驗毫不保留地寫在《海量資料庫解決方案》中的時候，我覺得我還是應該把我的一點經驗寫出來，這樣也許就能夠幫助更多的人。
現在回想起來，我的Oracle入門過程大致分為四個階段。
第一階段：從2004年到2006年8月，我用了大概兩年多的時間斷斷續續地看完了OCP 9i的一套培訓教材（一共4本書）。很慚愧，用了兩年多的時間才看完。但是大家要理解我，我本科和研究生都是學數學的，2004年以前連最基本的SQL都不會寫，而且那段時間項目的開發還是有一定的工作量的，我基本上只能夠利用業餘時間自學。
第二階段：從2006年8月到2008年年初，因為那時候我的Oracle已經有了一點基礎，所以我開始大量地看Oracle的各種官方文檔，但是這些文檔我大都只是過了一遍，唯一的例外就是《10gR2 Concepts》和《Oracle 10gR2 Clusterware and RAC Administration and Deployment Guide》，這兩本書我都分別看過兩遍。
第三階段：從2008年年初到現在，我開始在metalink上大量閱讀文章，在我真正開始接觸metalink的時候我才發現，哇塞，這是多么精彩的一個世界！在我看來，metalink就是最好的老師了！直到現在，我工作的第一件事情依然是把metalink打開，平常沒事就泡在上面，迄今為止，我已經在metalink上看過超過1500篇文章了。
第四階段：從2009年3月到現在，我開始仔細閱讀DSI（Data Server Internals）教材。DSI其實我看的並不多，迄今為止，只看過了如下幾本：
DSI303-Advanced Backup,Restore and Recovery Techniques
DSI401-Dumps Crashes and Corruptions
DSI402-Space and Transaction Management
DSI402e-Data types and block structures
DSI403e-Recovery Architecture Components
DSI404e-query_optimizer
DSI405-Performance Tuning
總的感覺是DSI沒什麼，真的沒有我想像的那么難。但是這裡我想說的是DSI應該在你具有一定的基礎後才開始看，早看反而無益！
前前後後六年的時間，當我看完DSI405後，我真的覺得自己的Oracle已經入門了。其實細心的朋友已經可以發現，我的Oracle入門過程用一句話來概括就是“循序漸進”。
當我看完DSI系列並且在我的個人網站上撰寫了100多篇文章後，終於迎來了屬於我自己的機會——我結識了Eygle和Kamus，並且有機會和他們一起開始迎接許多夢寐以求的挑戰。
一直以來，Eygle和Kamus都是我努力的目標，修訂的這三個多月雖然辛苦，但是能和自己的知音益友一起做事情，於我而言是非常榮幸也是非常開心的事情，再辛苦又算得了什麼。這次我修訂了第1部分的第1章、第2章和第2部分的第2章，交叉修訂了第1部分的第3章。在修訂過程中，我付出了大量的努力，以自己所學、所知去理解並傳達作者的真知灼見。然而再怎么盡心竭力，我們的工作也難免存在種種不足，但是我們確確實實已經盡力，剩下的只能交給讀者去評判吧。
雖然這次修訂的過程是極其痛苦的，在殫精竭慮之後常常會感覺很崩潰；但是如果能有機會讓我繼續修訂《海量資料庫解決方案》的後續書籍，我非常願意再多崩潰幾次。
崔華（Dbsnake）
2010年6月29日
好了，這就是幾位校譯者的心聲。現在這本書已經翻越了山川、民族與語言的障礙，來到中國讀者的面前，讓我們一起來閱讀和領會一下來自亞洲資料庫界的聲音吧！
目 錄
第1部分 影響數據讀取的因素
第1章 數據的存儲結構和特徵 1
1.1 表和索引分離型 5
1.1.1 堆表的結構 5
1.1.2聚簇因子（Cluster Factor） 10
1.1.3 影響讀取的因素 13
1.1.3.1 大範圍數據讀取的處理方案 14
1.1.3.2 提高聚簇因子的手段 17
1.2 索引組織表（Index-Organized Table） 19
1.2.1 堆表和索引組織表的比較 19
1.2.2 索引組織表的結構和特徵 20
1.2.3 邏輯ROWID和物理猜（Physical Guess） 22
1.2.4 溢出區（Overflow Area） 24
1.2.5 索引組織表的創建 25
1.3 聚簇表 26
1.3.1 聚簇表的概念 27
1.3.2 單表聚簇 29
1.3.3 複合表聚簇 31
1.3.4 聚簇表的代價 34
1.3.5 哈希聚簇 39
第2章 索引的類型和特徵 43
2.1 B-Tree 索引 44
2.1.1 B-Tree 索引的結構 44
2.1.2 B-Tree 索引的套用 47
2.1.3反向鍵索引52
2.2 點陣圖索引 53
2.2.1 點陣圖索引的形成背景 54
2.2.2 點陣圖索引的結構和特徵 55
2.2.3 點陣圖索引的讀取 57
2.3 基於自定義的函式索引 60
2.3.1 基於自定義的函式索引的概念和結構 60
2.3.2 基於自定義函式索引的約束 61
2.3.3 基於自定義函式索引的靈活運用 64
第3章 SQL的執行計畫（Explain Plan） 74
3.1 SQL和最佳化器 75
3.1.1 最佳化器的作用和人的作用 77
3.1.2 最佳化器的類型 80
3.1.2.1 基於規則的最佳化器 82
3.1.2.2 基於成本的最佳化器 86
3.1.2.3 最佳化器目標的選擇 93
3.1.2.4 執行計畫的固定化方案 97
3.1.2.5 最佳化器的局限 103
3.1.3 最佳化器的最最佳化步驟 106
3.1.4 查詢語句的轉換 112
3.1.4.1 傳遞性規則 113
3.1.4.2 視圖合併（View Merging） 116
3.1.4.3 查看用戶定義的綁定變數122
3.1.5 開發者的作用 123
3.2 執行計畫的類型 126
3.2.1 掃描的基本類型 126
3.2.1.1 全表掃描127
3.2.1.2 ROWID掃描 132
3.2.1.3 索引掃描 133
3.2.1.4 B-Tree聚簇讀取（Cluster Access） 138
3.2.1.5 哈希聚簇讀取（Hash Cluster Access） 139
3.2.1.6 採樣表掃描（Sample Table Scan） 140
3.2.2 表連線的執行計畫 143
3.2.2.1 嵌套循環連線（Nested Loops Join） 143
3.2.2.2 排序合併連線（Sort Merge Join） 146
3.2.2.3 哈希連線（Hash Join） 148
3.2.2.4 半連線（Semi Join） 149
3.2.2.5 笛卡兒連線 151
3.2.2.6 外連線（Outer Join） 154
3.2.2.7 索引連線 159
3.2.3 其他運算方式的執行計畫 161
3.2.3.1 IN-List疊代執行計畫 162
3.2.3.2 連鎖執行計畫 163
3.2.3.3 遠程執行計畫 165
3.2.3.4 排序操作執行計畫 168
3.2.3.5 集合操作執行計畫 171
3.2.3.6 COUNT(STOPKEY)執行計畫 174
3.2.4 點陣圖（Bitmap）執行計畫 175
3.2.4.1 各種條件運算符的點陣圖執行計畫 176
3.2.4.2 子查詢執行計畫 182
3.2.4.3 與B-Tree索引相結合的執行計畫 184
3.2.5 其他特殊處理的執行計畫 185
3.2.5.1 遞歸展開（Recursiveimplosion）執行計畫 186
3.2.5.2 修改子查詢執行計畫 191
3.2.5.3 特殊類型的執行計畫 193
3.3 執行計畫的控制 203
3.3.1 提示的活用準則 204
3.3.2 使用提示實現最最佳化目標 206
3.3.3 使用提示改變表連線順序 207
3.3.4 表連線方式選擇過程中提示的使用 208
3.3.5 並行操作中提示的使用 209
3.3.6 數據讀取方法選擇中提示的使用 211
3.3.7 查詢轉換（Query Transformation）過程中提示的使用 214
3.3.8 其他提示 216
第4章 構建索引的戰略方案 221
4.1 索引的選定準則 222
4.1.1 不同類型表的索引套用準則 223
4.1.2 離散度和損益分界點 227
4.1.3 索引合併和組合索引的比較 229
4.1.4 組合索引的特徵 232
4.1.5 組合索引中列序的決定準則 239
4.1.6 索引選定步驟 242
4.2 決定聚簇類型的準則 263
4.2.1 全局性聚簇 263
4.2.2 局部性聚簇 265
4.2.3 單表聚簇 266
4.2.4 單位聚簇大小的決定 267
4.2.5 確保聚簇被使用的措施 270
第2部分 最最佳化數據讀取方案
第5章 局部範圍掃描（Partial Range Scan） 274
5.1 局部範圍掃描的概念 277
5.2 局部範圍掃描的套用原則 282
5.2.1 局部範圍掃描的條件 282
5.2.2 不同最佳化器模式下的局部範圍掃描 285
5.3 提高局部範圍掃描執行速度的原理 286
5.4 向局部範圍掃描引導的方法 290
5.4.1 利用訪問路徑實現對Sort的代替 290
5.4.2 只使用索引的局部範圍掃描 293
5.4.3 MIN、MAX 的處理 294
5.4.4 FILTER型局部範圍掃描 299
5.4.5 ROWNUM的靈活運用 301
5.4.6 利用嵌套視圖的局部範圍掃描 307
5.4.7 利用函式的局部範圍掃描 309
5.4.8 利用查詢語句二元化特性的局部範圍掃描 317
5.4.9 Web留言板中的局部範圍掃描 319
第6章 表連線的最最佳化方案 337
6.1 JOIN和LOOP QUERY的比較 340
6.1.1 全部範圍掃描方式下的比較 342
6.1.2 局部範圍掃描方式下的比較 350
6.2 連線條件狀態對表連線的影響 352
6.2.1 連線條件正常 354
6.2.2 連線條件一邊異常 359
6.2.3 連線條件兩邊異常 362
6.3 各種表連線方式的特徵及活用方案 366
6.3.1 嵌套循環連線 367
6.3.1.1 嵌套循環連線的基本概念 368
6.3.1.2 嵌套循環連線順序的決定 371
6.3.2 排序合併連線 380
6.3.3 嵌套循環連線和排序合併連線的比較 384
6.3.4 哈希連線（Hash Join） 388
6.3.4.1 IN-MEMORY哈希連線 393
6.3.4.2 延遲哈希連線 396
6.3.5 半連線（Semi Join） 399
6.3.5.1 半連線的概念和特徵 400
6.3.5.2 半連線的執行計畫 402
6.3.6 星型（Star）連線 418
6.3.7 星變形（Star Transformation）連線 426
6.3.8 點陣圖連線索引 438
