如何設計乙個關係型資料庫?分為儲存與程式例項
程式例項:
儲存管理
快取機制
sql解析
日誌管理
許可權劃分(dba)
容災機制(異常機制)
索引管理(優化資料查詢)
鎖管理(支援併發操作)
儲存:檔案系統
索引模組:
為什麼要使用索引?
快速查詢資訊,避免全表掃瞄,降低io操作次數
什麼樣的資訊能成為索引?
主鍵，唯一鍵
索引的資料結構:
建立二叉查詢樹進行二分查詢
建立b-tree結構進行查詢
建立b+-tree結構進行查詢--更加適合用來儲存索引
建立hash結構進行查詢
b-tree定義
根節點至少包括兩個孩子
樹中每個節點最多含有m個孩子(m>=2)
除了根節點和葉節點外,其他每個節點至少有ceil(m/2)個孩子
所有葉子節點都位於同一層
b+-tree的定義
非葉子節點的子樹指標與關鍵字個數相同
非葉子節點的子樹指標p[i],指向關鍵字值(k[i],k[i+1])的子樹
非葉子節點僅用來索引,資料都儲存在葉子節點中
所有葉子節點均有乙個鏈指標指向下乙個葉子節點
b+-tree更加適合用來做儲存索引
b+樹的磁碟讀寫代價更低(內部結構並沒有指向關鍵字的具體指標,不存放資料，只存放索引資訊,內部節點更小,載入的索引量更多)
b+樹的查詢效率更加穩定(任何關鍵字的查詢都必須走一條根節點到葉子結點的路，所有關鍵字的查詢長度相同，因此每個關鍵字查詢的效率也相同)
b+樹更有利於對資料庫的掃瞄(只需要遍歷葉子結點，就可以解決對資料庫中全部關鍵字的掃瞄,對資料庫中經常使用的範圍查詢非常方便)
hash索引-缺點
(hash索引將關鍵字的索引放入buckets區域的桶中,將索引值對應的entries全部載入到記憶體中)
僅僅能滿足「=」，「in」，不能使用範圍查詢(只能使用等值過濾)
無法被用來避免資料的排序操作
不能利用部分索引鍵查詢(使用組合鍵的索引查詢，而不是部分鍵的索引查詢)
不能避免表掃瞄(索引的hash值可能相同，需要對比buckets中的具體值進行對比)
遇到大量hash值相等的情況後效能並不一定就會比b-tree索引高
密集索引和稀疏索引的區別
密集索引檔案中的每個搜尋碼值都對應乙個索引值
稀疏索引檔案只為索引碼的某些值建立索引項
innodb:
若乙個主鍵被定義,該主鍵則作為密集索引
若沒有主鍵被定義,該錶的第乙個唯一非空索引則作為密集索引
若不滿足以上條件,innodb內部會生成乙個隱藏主鍵(密集索引)
非主鍵索引儲存相關鍵位和其對應的主鍵值,包含兩次查詢.
mysql 雜湊索引 MySQL索引之雜湊索引
雜湊索引 hash index 建立在雜湊表的基礎上，它只對使用了索引中的每一列的精確查詢有用。對於每一行，儲存引擎計算出了被索引的雜湊碼 hash code 它是乙個較小的值，並且有可能和其他行的雜湊碼不同。它把雜湊碼儲存在索引中，並且儲存了乙個指向雜湊表中的每一行的指標。在mysql中，只有me...
mysql雜湊索引用途 MySQL 雜湊索引
雜湊索引基於雜湊表實現，只有精確匹配索引所有列的查詢才有效。在mysql中只有memory引擎顯示支援雜湊索引，也是memory引擎表的預設索引型別。memory引擎是支援非唯一雜湊索引的。如果多個列的雜湊值相同，索引會以鍊錶 的方式存放多個記錄指標道同乙個雜湊條目中。舉個粒子 create tab...
Mysql 雜湊索引（hash index）
雜湊索引本身在實際專案中使用的並不多，但是常常在面試的時候拿來與b tree 索引等進行比較提問，那麼雜湊索引到底是怎樣的結構？又適用於哪些場景呢？有哪些優點和缺點呢？雜湊索引 hash index 是基於雜湊表實現，只有精確匹配索引所有列，查詢才會有效。對於每一行資料，儲存引擎都會對所有的索引列計...