 |
-- 會員 / 註冊 --
|
 |
|
|
|
數據庫索引設計與優化 ( 簡體 字) |
| 作者：曹怡倩,趙建偉 | 類別：1. -> 資料庫 -> 綜合 |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 41859
詢問書籍請說出此書號！【缺書】
NT售價： 395 元 |
| 出版日：6/1/2015 |
| 頁數：320 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121260544 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：推薦序一
2015年，我很欣喜地看到這本書終于被真正的技術粉們翻譯成了中文。
這本寫作于2005年的著作，是少數能夠穿越十年仍然歷久彌新的經典著作之一。譯者曹怡倩和趙建偉是支付寶的資深數據庫專家，也是童家旺的得意門生，他們的經驗和理解為本書增色良多。我在學習過程中也曾經從本書的英文版中獲益，所以當旺旺委托我寫一段文字時，我欣然受命，但是其實他才是這本書的知音，我曾經在他的多次公開演講中聽到他鄭重推薦此書，并引用書中的方法達成實踐。今天，兩位作者的真知灼見跨越時間和空間，在中文世界里找到喜愛的讀者們，這是作者們的欣慰，更是讀者們的幸運。
在RDBMS的世界里，直到今天，索引仍然是無與倫比的重要環節——走過千山萬水，優化仍然要回歸到和索引糾纏不清的本質上來。作者在第5章提出“前瞻性的索引設計”，其中的觀點之一是“設計索引，使所有查詢語句都運行得足夠快”，這讓我想到2011年我們翻譯的韓國著作《海量數據庫解決方案》一書，李華植先生在書中同樣提出了“戰略性索引設計方案”，實在是具有異曲同工之妙，大家都著眼于如何使用更合理的索引去滿足盡可能多的SQL訪問需求。而為了解決開發環節中的不良SQL性能問題，云和恩墨甚至開發了一款專門的軟件用于SQL審核，其中的多個維度指標仍然是考量索引的。
大道至簡，從最基本的起點出發，才有可能從最根本上解決我們面對的復雜終極問題。當然，今天我們對于索引的關注已經不僅僅是有無，而已擴展到索引的各種訪問方式，索引全掃描、索引跳躍式掃描等，細微之處更見功夫。
技術的另外一大迷人之處在于其無窮的細節變化和無限的可能。針對作者在第1章中提到的種種誤區，我們在閱讀時都可以細細地思量并引發探討。比如作者提到的“誤區2 單表的索引數不要超過6個”，在很長一段時間內，我對此并沒有深刻的認識和經驗，直到2010年在一個客戶的環境中遇到了非常棘手的問題，我的確史無前例地分析了索引個數對于Oracle SQL解析性能的影響。要知道，在硬解析的過程中，CBO需要對所有可能發揮作用的索引進行非常詳盡的成本計算和評估，這在Oracle中涉及了ROW CACHE的算法管理，在串行Latch的守護下，如果索引的數量增多，無疑會降低解析的速度。我還意外地發現在dc_object_ids的使用上，效率不佳——你可能也注意到了，在Oracle 11g中，這個資源消失不見了。就是這么好玩，你總會發現例外。而且這一切發生在SQL開始執行之前，我們更多時候關注的是索引好不好、快不快，可能我們忽略了在SQL開始執行之前的解析環節中就可能存在無法規避的問題。
在2008年Oracle推出的Exadata一體機上，Oracle更加喜歡在全掃描的過程中通過智能掃描（Smart Scan）進行數據卸載，而存儲索引更是一個讓人目瞪口呆的設計，你可能覺得這個基于內存的設計根本就不是索引！再然后，在2014年Oracle推出了IMO之后，Larry居然宣布，有了這個特性趕緊去干掉一堆索引吧，這會讓OLTP更流暢。
各種好玩啊！技術世界就是如此變化多端，曲曲折折！
你也必須覺得好玩，才能在技術的世界里找到快樂！
在這本書中，你一定能夠找到點燃你技術熱情的火花！
——蓋國強（Oracle ACE總監，云和恩墨創始人）
2015年4月于北京
推薦序二
經過多年的發展，關系型數據庫已經成為一個企業IT架構的核心，誕生了包含Oracle、MySQL、DB2、Microsoft SQL Server、Sybase、PostgreSQL這樣的數據庫。上述這些傳統的數據庫都強烈地依賴于索引的設計與規劃。不夸張地說，一個應用是否合格的關鍵就在于數據庫索引的設計與優化。
在工程領域，很多數據庫工程師們都積累了對于索引設計與優化的經驗，可惜很少有書籍系統地介紹這部分內容，這導致網上存在很多錯誤的觀念。可喜的是本書詳細介紹了一種簡單、高效的數據庫索引設計方法，可讓讀者對數據庫的索引設計快速進階。此外，本書通過大量的實例分析了關系型數據庫的訪問路徑選擇原理，對實踐有著實際的指導意義。最為關鍵的是，這些原理與知識對于所有關系型數據庫都是通用的，甚至對于目前出現的NoSQL數據庫也是具有指導意義的。
本書對于想要理解數據庫索引設計方法，以及數據庫優化器訪問路徑選擇原理的讀者都具有現實的指導意義。希望將本書推薦給所有從事數據庫相關工作的人員，它的內容不局限于具體的數據庫類型，是一本修煉內功的好書，看完之后定能解決在工程中遇到的各種索引設計與優化問題。
姜承堯
網易杭州研究院數據庫技術組負責人
推薦序三
一直以來，我們都將數據庫行業鼻祖薩師?老師主編的《數據庫系統概論（第三版）》作為葵花寶典，每年都要對其核心章節讀上1~2遍，也曾讀過他人翻譯的《數據庫系統面向應用的方法》。總體而言這兩本書在關系型數據庫的基礎知識和技術原理等方面基本一致，也有互補的技術內容，但關于索引設計與優化方面的內容尚有不足，國內外也未發現這方面較好的書籍。好友童家旺找我為其徒弟曹怡倩和趙建偉翻譯的書籍作序，我看到書名《數據庫索引設計與優化》時便欣然答應了，因為此書能填補國內的空白，為眾多技術人員帶去福音。
在閱讀書籍全文內容的過程中，我深刻地體會到國際友人寫書風格非常值得學習，全篇使用示例與公式一步一步分析、計算和驗證，不僅得出經得起推敲的方法論，而且深入淺出地講述了相關的技術原理，既體現出作者的嚴謹風格，又便于讀者學習、記憶和理解。閱讀過程中能發現本書的專業術語翻譯得非常精湛，對原理、算法、方法論、技術常識等內容的描述，更讓人讀起來有讀原著作品的口感，這體現了譯者深厚的數據庫理論功底，以及對本書內容的深刻理解，甚至已有超越原著的水準。
雖然近二十年中數據庫理論知識未有任何質的變化，但計算機軟硬件技術的飛速發展促進了多種數據庫管理系統實現算法的革新。隨著軟硬件技術算法實現的變革，早期關于索引創建與優化的部分準則已不適應當下，故本書籍從索引相關的基礎知識和早期建立準則誤區出發，介紹了硬盤處理器內存與索引的關系、其中的技術原理和索引原理，以及不同數據庫產品之間的異同、SQL處理過程與索引的關聯性、如何創建理想和前瞻性的索引、索引設計需要關注和平衡的點、不同應用場景下的索引設計技巧與方法論、如何規避索引的弊端、數據庫管理系統的索引限制、如何讓優化器運行更佳，總結了當下設計優秀索引的準則。
本書按照由淺入深的方式安排內容，清楚闡釋了原著作者想要解釋的兩個問題：如何量化索引和優化器的成本，如何從 CPU和執行時間的角度量化運行過程。
書中使用了Oracle、DB2和SQL Server 這三種數據庫的大量案例，介紹了它們的異同與各自的特性，絕大部分內容也同樣適合于MySQL和PostgreSQL數據庫產品。個人認為本書同薩老師主編的書籍一樣可奉為葵花寶典，是值得DBA們人人收藏的一本書，也適合作為云計算平臺研發自動化SQL審核與索引創建組件研發工程師的工具書。
金官丁
書于2015年4月20日
推薦序四
本書原著是數據庫領域的重要理論大作，幾年前童家旺先生就推薦過此書，在《高性能MySQL》一書中也推薦過它，據說他還要求每位徒弟都熟讀此書，可見其重要性。本書花了大量篇幅講解索引基礎的各種理論知識，以及如何綜合評估索引使用的代價，而非簡單介紹SQL如何編寫，或者如何進行SQL優化等內容。認真通讀本書之后，相信各位讀者對數據庫的索引設計、代價評估等方面就基本可以駕輕就熟了。本書經知含（曹怡倩）等人的悉心翻譯，終于有了中文版，是國內廣大DBA同行的福音，強烈建議購買閱讀。
葉金榮
譯者序一
記得第一次接觸到這本書是在2011年的時候，那時我剛畢業參加工作不久，在公司里還處于學習知識和熟悉業務的階段，當時帶我的師傅童家旺先生經常會介紹一些他認為不錯的書籍給團隊的同事們閱讀，這本Relational Database Index Design and the Optimizers就在他推薦給我們幾位入職不久的新人的書單之中。我最初閱讀的是書中第3章至5章的內容，讀完后感到非常地痛快，只看一遍，所有的原理就都能清晰地呈現在腦海之中，于是隨即將全書的其余章節也通讀完成。從這本書中所學到的知識對我之后的工作帶來了極大的幫助，使我在應用系統的索引設計及SQL調優上節省了大量的精力且取得了不錯的效果。之所以能有如此成效，完全得益于Tapio Lahdenm＆auml;ki和Michael Leach兩位作者的貢獻，是他們將寶貴的經驗與智慧與廣大讀者分享。本書從表和索引結構開始，層層深入，通過大量的案例系統性地闡釋了關系型數據庫的訪問路徑選擇原理，以及表和索引的結構、掃描方式、硬件等對性能的影響；詳盡地講解了如何快速地估算SQL運行的CPU及執行時間的方法，使讀者能夠運用量化的方法進行判斷和優化，指導關系型數據庫的索引設計，真正做到知其所以然，進而能夠舉一反三，靈活運用于各類場景之中。
當得知有幸能夠參與本書中文版的翻譯工作時，我們感到非常興奮，迫切地想把它翻譯出來與更多的朋友分享。但當真正開始著手翻譯時，才體會到這其中的艱難以及身負的責任，以至于有段時間愈翻譯愈感到焦慮，深恐譯本無法傳達作者之原意。對于翻譯中遇到的一些疑難問題，有時會反反復復閱讀相關內容數遍，查閱各種資料以盡力獲得較為準確的譯法。加之我和趙建偉工作都較為繁忙，最終的交稿時間遠遠超出了原定計劃。在此特別感謝王中英編輯在此過程中的督促、鼓勵以及對翻譯疏漏之處的校正。
本書由螞蟻DBA團隊的多位同事共同翻譯完成，其中第4、7、10、12、14、16章由曹怡倩翻譯，第3、9、13、15章由趙建偉翻譯，第1、2、5、6、8、11章分別由劉曉軍、葉瑩佼、曹棲鋒、柯翔宇、藺瑞超、樊振華翻譯。全書校稿及前言、術語表部分的翻譯由曹怡倩完成。感謝恩師童家旺先生在全書翻譯過程中的解惑和幫助。
本書原文通俗曉暢，但因我們個人水平及時間的限制，譯文中難免存在不準確或是不通順之處，這全是我們譯者的責任，與作者及幫忙的朋友無關；如有識者，望不吝賜教。
感謝電子工業出版社編輯張春雨、王中英以及其他所有工作人員在各方面的鼎力支持與幾近無限的耐心。感謝在本書翻譯過程中給予了我們如此多幫助與支持的朋友、同事和家人們。
感謝阿里巴巴DBA二部團隊同事和領導給予的支持與幫助。感謝恩師童家旺先生在全書翻譯過程中的解惑和幫助。感謝父母一直以來的關心照顧和體諒，使我能夠有更多的精力專注于本書的翻譯工作。
曹怡倩
譯者序二
記得2010年7月畢業進入支付寶數據庫管理團隊，擔任開發DBA一職，阿里系各子公司是國內當時為數不多的在數據庫團隊劃分開發DBA和運維DBA兩種角色的公司，開發DBA的主要職責包括評估業務開發人員數據庫使用的申請，SQL審核，上線評估，運行監控，容量規劃等，貫穿整個產品的生命周期，其中SQL審核尤為煩瑣和重要，在業務迅猛發展和小機+存儲架構流行的年代，一條爛SQL足以搞垮多條業務產品線，修復的代價比較大，周期也比較長。
接觸了一段工作時間后，我的師傅童家旺先生推薦我閱讀本書的英文原版Relational Database Index Design and the Optimizers，當時拿到這本書的時候不以為然，覺得在關系數據庫領域遇到SQL性能問題時，無非就是添加B樹索引。但當我真正翻開這本書的時候，真的是愛不釋手，一口氣把它讀完，仍意猶未盡。這本書不僅講述了如何建立三星索引的方法論，更重要的是給出了基于硬件和軟件環境下索引設計的量化評估的方法和實踐，掌握了這些方法后，你將能夠提前量化業務SQL上線運行情況，并指導后期的容量評估。這本書并沒有限定具體的商業或者開源的關系型數據庫產品，而是講述通用的理論和方法。所以，強烈建議數據庫從業人員，使用關系型數據庫的開發人員閱讀本書，它會給大家帶來體系化的理論和方法。
在此，感謝原支付寶數據庫管理團隊的領導和同事們合力完成本書的翻譯工作，同時要感謝我的家人，是你們不辭辛苦地照顧家庭，我才能夠在工作之余專注于本書的翻譯。希望大家享受這本書。
趙建偉
2015年5月于杭州
前言
關系型數據庫至今已存在了三十多年。在其發展早期，由于硬件資源限制及優化器成熟度的不足，性能問題非常普遍，因此性能成為了人們優先考慮的事項。但現在情況已經不同了，硬件及軟件以超出人們想象的速度發展了起來，系統已經能夠自己關心自己的性能了，這在之前看來是不可思議的！但比這些資源增長速度更快的是隨之產生的大量信息以及這些信息所衍生出的活動。另外，有一個重要的硬件還沒有跟上整體的發展速度：雖然磁盤已變得更大且異常廉價，但它們的訪問速度仍相對較慢。因此，許多老問題其實并沒有消失——它們只是變換了形式。這其中的有些問題可能會造成巨大的影響——那些所謂的應該只需運行不到一秒的“簡單”查詢實際卻運行了幾分鐘或更久，盡管所有的書中都寫了如何正確編寫查詢、如何組織表，以及應當按照什么規則來決定將哪些列添加至索引上。所以，很明顯，我們需要有一本能夠突破常規的書，真正開始思考為何現今仍有這么多人還會遇到如此多的問題。
為了滿足這一需求，我們認為必須關注兩個問題。第一個必須關注的對象是關系型系統中用于確定如何以最高效的方式查詢所需數據的部分（我們稱其為SQL優化器）。第二個必須關注的是索引及表是以何種方式被掃描的。我們試著把自己放在優化器的角度思考問題，也許當我們理解為什么可能存在問題時，我們就能夠做出改變。幸運的是，我們需要知道的有關優化器的內容其實非常少，但非常重要。本書與其他同領域的書籍的一個很重要的區別在于，我們不會提供大量的用于指導SQL編寫以及表和索引設計的規則和語法。這不是一本告訴你在各種場景下應當使用哪一個SQL WHERE語句的書，也不是一本告訴你應當使用什么語法的書。如果我們努力遵循一大堆復雜、模糊甚至可能不完整的指導原則，那么我們就是在走前人走過的老路。相反，如果我們能夠理解SQL請求對關系型系統造成的潛在影響，并知道如何控制這一影響，那么我們就能夠理解、控制、最小化甚至避免這些問題。
本書的第二個目的是展示如何使用這些知識從CPU和執行時間的角度量化運行過程。只有這樣，我們才能真正判斷我們設計的表和索引是否合適，我們需要用真實的數字來展示優化器是如何思考的、掃描將耗費多少時間，以及需要進行哪些改動以提供滿意的性能。不過，最重要的是，我們必須能夠方便且快速地完成這一評估過程，這就要求我們必須將關注點放在少數幾個真正重要的問題上，而不是將關注點放在那些不那么重要的細節上（許多人都被這些細節問題困擾過）。所以，關鍵就是要關注少數核心領域，并能夠說出這需要花費多少時間或成本。
同樣是由于我們專注于核心問題，所以我們還能提供另一個優勢。對于那些可能使用多個關系型產品（即便來自相同的供應商）的人，由于我們在本書中所使用的是一種適用于所有關系型產品的通用方法，所以使用者就不需要閱讀和掌握多套截然不同的規則和建議。所有“真正的”關系型系統的優化器都有一個相同的任務：它們都必須要掃描索引和表。它們都使用異常相似的方式來處理這些操作（雖然他們對其有各自不同的描述方式）。當然，它們之間的確存在著一些差異，但是我們可以毫不費力地處理這些不同。
也正是由于相同的原因，本書的讀者對象包括：認為了解SQL性能方面的知識或如何有效設計索引的知識能給自己帶來益處的人，直接負責索引設計的人，編寫SQL語句用于查詢或作為應用程序一部分的人，以及那些負責維護關系型數據和關系型環境的人。只要你覺得需要對自己所做的事情的性能影響負責，那么你都將不同程度地從本書中受益。
最后，用一句話概括本書目標讀者所需具備的背景知識：我們假定讀者已經具備了SQL這一關系型語言相關的知識。考慮閱讀本書的人應該已經具備了對計算機系統的大體理解。除此以外，能幫到讀者的最重要的品質也許就是對事物運行原理的好奇和興趣了，還有想把事情做得更好的渴望。另一方面，在眾多擁有幾十年的關系型系統經驗的人中，有兩類人也會從本書受益：第一類是那些根據詳細的規則手冊良好地管理了系統很多年的人，他們想通過理解這些規則適用的原因來使自己的工作更輕松一些；第二類是那些已經使用了本書中所描述的技術很多年，但對于新硬件所帶來的改善并不贊賞的人。
本書中的絕大部分觀點及使用的技術都是原創的，因此很少有對外部出版物及其他作者成果的引用。在本書的創作過程中，我們非常感謝給予了我們如此多幫助和鼓勵的朋友及同事們。感謝Matti St＆aring;hl在全書撰寫過程中所給予的詳細指點及批判性但極其有用的建議。感謝Lennart Hen＆auml;ng、Ari Hovi、Marja K＆auml;rmeniemi和Timo Raitalaakso的幫助和校對，也感謝Akira Shibamiya在關系型性能公式上的原創工作。另外，還要感謝許許多多的學生和數據庫顧問們，感謝他們提供的對于實際問題及其解決方案的深入見解。最后，特別感謝Meta和Lyn，沒有他們的鼓勵與支持，本書不可能完成，Meta還特別為本書設計了封面，與全書的主旨非常契合。
Tapio Lahdenm＆auml;ki（斯姆勒尼科，斯洛文尼亞）
Michael Leach（什魯斯伯里，英格蘭） |
內容簡介：本書提供了一種簡單、高效、通用的關系型數據庫索引設計方法。作者通過系統的講解及大量的案例清晰地闡釋了關系型數據庫的訪問路徑選擇原理，以及表和索引的掃描方式，詳盡地講解了如何快速地估算SQL運行的CPU時間及執行時間，幫助讀者從原理上理解SQL、表及索引結構、訪問方式等對關系型數據庫造成的影響，并能夠運用量化的方法進行判斷和優化，指導關系型數據庫的索引設計。 |
目錄：第1章 概述 1
關于SQL性能的另一本書 1
不合適的索引 3
誤區和誤解 4
誤區1：索引層級不要超過5層 5
誤區2：單表的索引數不要超過6個 6
誤區3：不應該索引不穩定的列 6
示例 7
磁盤驅動器使用率 7
系統化的索引設計 8
第２章 表和索引結構 10
介紹 10
索引頁和表頁 11
索引行 11
索引結構 12
表行 12
緩沖池和磁盤I/O 12
從DBMS緩沖池進行的讀取 13
從磁盤驅動器進行的隨機I/O 13
從磁盤服務器緩存進行的讀取 14
從磁盤驅動器進行的順序讀取 15
輔助式隨機讀 15
輔助式順序讀 18
同步I/O和異步I/O 18
硬件特性 19
DBMS特性 20
頁 20
表聚簇 21
索引行 21
表行 22
索引組織表 22
頁鄰接 23
B樹索引的替代品 24
聚簇的許多含義 25
第3章 SQL處理過程 27
簡介 27
謂詞 27
評注 28
優化器及訪問路徑 28
索引片及匹配列 29
索引過濾及過濾列 29
訪問路徑術語 31
監控優化器 32
幫助優化器（統計信息） 32
幫助優化器（FETCH調用的次數） 32
何時確定訪問路徑 33
過濾因子 34
組合謂詞的過濾因子 35
過濾因子對索引設計的影響 37
物化結果集 39
游標回顧 39
方式1：一次FETCH調用物化一條記錄 40
方式2：提前物化 41
數據庫設計人員必須牢記 41
練習 41
第4章 為SELETE語句創建理想的索引 43
簡介 43
磁盤及CPU時間的基礎假設 44
不合適的索引 44
三星索引——查詢語句的理想索引 45
星級是如何給定的 46
范圍謂詞和三星索引 48
為查詢語句設計最佳索引的算法 49
候選A 50
候選B 50
現今排序速度很快——為什么我們還需要候選B 51
需要為所有查詢語句都設計理想索引嗎 52
完全多余的索引 52
近乎多余的索引 53
可能多余的索引 53
新增一個索引的代價 54
響應時間 54
磁盤負載 55
磁盤空間 56
一些建議 57
練習 58
第5章 前瞻性的索引設計 59
發現不合適的索引 59
基本問題法（BQ） 59
注意 60
快速上限估算法（QUBE） 61
服務時間 62
排隊時間 62
基本概念：訪問 63
計算訪問次數 65
FETCH處理 66
主要訪問路徑的QUBE示例 67
使用滿足需求的成本最低的索引還是所能達到的最優索引：示例1 72
該事務的基本問題 73
對該事務上限的快速估算 73
使用滿足需求的成本最低的索引還是所能達到的最優索引 74
該事務的最佳索引 75
半寬索引（最大化索引過濾） 75
寬索引（只需訪問索引） 76
使用滿足需求的成本最低的索引還是所能達到的最優索引：示例2 77
范圍事務的BQ及QUBE 78
該事務的最佳索引 79
半寬索引（最大化索引過濾） 80
寬索引（只需訪問索引） 81
何時使用QUBE 82
第6章 影響索引設計過程的因素 83
I/O時間估算的驗證 83
多個窄索引片 84
簡單就是美（和安全） 86
困難謂詞 87
LIKE謂詞 87
OR操作符和布爾謂詞 88
IN謂詞 89
過濾因子隱患 90
過濾因子隱患的例子 92
最佳索引 95
半寬索引（最大化索引過濾） 96
寬索引（只需訪問索引） 97
總結 97
練習 99
第7章 被動式索引設計 100
簡介 100
EXPLAIN描述了所選擇的訪問路徑 101
全表掃描或全索引掃描 101
對結果集排序 101
成本估算 102
數據庫管理系統特定的EXPLAIN選項及限制 102
監視揭示現實 103
性能監視器的演進 104
LRT級別的異常監視 106
程序粒度的均值是不夠的 106
異常報告舉例：每個尖刺一行 106
問題制造者和受害者 108
有優化空間的問題制造者和無優化空間的問題制造者 108
有優化空間的問題制造者 109
調優的潛在空間 111
無優化空間的問題制造者 114
受害者 115
查找慢的SQL調用 117
調用級別的異常監視 118
Oracle舉例 121
SQL Server舉例 123
結論 125
數據庫管理系統特定的監視問題 126
尖刺報告 127
練習 127
第8章 為表連接設計索引 129
簡介 129
兩個簡單的表連接 131
例8.1：CUST表作為外層表 131
例8.2：INVOICE表作為外層表 132
表訪問順序對索引設計的影響 133
案例研究 133
現有索引 136
理想索引 142
理想索引，每事務物化一屏結果集 146
理想索引，每事務物化一屏結果集且遇到FF缺陷 149
基本連接的問題（BJQ） 151
結論：嵌套循環連接 153
預測表的訪問順序 153
合并掃描連接和哈希連接 155
合并掃描連接 155
例8.3：合并掃描連接 155
哈希連接 157
程序C：由優化器選擇MS/HJ（在現有索引條件下） 158
理想索引 159
嵌套循環連接VS. MS/HJ及理想索引 161
嵌套循環連接VS. MS/HJ 161
嵌套循環連接VS.理想索引 162
連接兩張以上的表 163
為什么連接的性能表現較差 166
模糊的索引設計 166
優化器可能選擇錯誤的表訪問路徑 166
樂觀的表設計 166
為子查詢設計索引 167
為UNION語句設計索引 167
對于表設計的思考 167
冗余數據 167
無意識的表設計 171
練習 173
第9章 星型連接 175
介紹 175
維度表的索引設計 177
表訪問順序的影響 178
事實表的索引 179
匯總表 182
第10章 多索引訪問 184
簡介 184
索引與 184
與查詢表一同使用索引與 186
多索引訪問和事實數據表 187
用位圖索引進行多索引訪問 187
索引或 188
索引連接 189
練習 190
第11章 索引和索引重組 191
B樹索引的物理結構 191
DBMS如何查找索引行 192
插入一行時會發生什么 193
葉子頁的分裂嚴重嗎 194
什么時候應該對索引進行重組 196
插入模式 196
索引列的穩定性 205
長索引行 207
舉例：對順序敏感的批處理任務 208
表亂序（存在聚簇索引） 211
表亂序（沒有以CNO開頭的聚簇索引） 212
存儲在葉子頁中的表行 212
SQL Server 212
Oracle 213
索引重組的代價 214
分裂的監控 215
總結 216
第12章 數據庫管理系統相關的索引限制 219
簡介 219
索引列的數量 219
索引列的總長度 220
變長列 220
單表索引數量上限 220
索引大小上限 220
索引鎖定 221
索引行壓縮 221
數據庫管理系統索引創建舉例 222
第13章 數據庫索引選項 224
簡介 224
索引行壓縮 224
索引鍵以外的其他索引列 225
唯一約束 227
從不同的方向掃描數據庫索引 227
索引鍵截斷 228
基于函數的索引 228
索引跳躍式掃描 229
塊索引 230
數據分區的二級索引 230
練習 231
第14章 優化器不是完美的 232
簡介 232
優化器并不總能看見最佳方案 234
匹配及過濾問題 234
非BT謂詞 234
無法避免的排序 237
不必要的表訪問 238
優化器的成本估算可能錯得離譜 239
使用綁定變量的范圍謂詞 239
偏斜分布 241
相關列 242
部分索引鍵的警示故事 243
成本估算公式 246
估算I/O時間 247
估算CPU時間 248
協助優化器處理估算相關的問題 249
優化器的問題是否會影響索引設計 252
練習 253
第15章 其他評估事項 254
QUBE公式背后的假設條件 254
內存中的非葉子索引頁 255
例子 255
磁盤服務器讀緩存的影響 256
緩沖子池 258
長記錄 259
慢速順序讀 259
實際的響應時間可能比QUBE評估值短得多 259
葉子頁和表頁緩存在緩沖池中 260
識別低成本的隨機訪問 262
輔助式隨機讀取 262
輔助式順序讀 265
評估CPU時間（CQUBE） 265
單次順序訪問的CPU時間 265
單次隨機訪問的CPU時間 267
單次FETCH調用的CPU時間 269
每排序一行的平均CPU時間 270
CPU評估舉例 270
寬索引還是理想索引 270
嵌套循環（及反范式化）還是MS/HJ 271
合并掃描與哈希連接的比較 274
跳躍式順序掃描 275
CPU時間仍然不可忽視 276
第16章 組織索引設計過程 277
簡介 277
計算機輔助式索引設計 278
設計出色索引的9個步驟 280
參考文獻 282
術語表 283
索引 291 |
| 序： |
|
