InnoDB 中文參考手冊 --- 12 檔案空間管理和磁碟 I/O (轉)

InnoDB 中文參考手冊 --- 12 檔案空間管理和磁碟 I/O (轉)[@more@] words" content="My,InnoDB,4.1.0,Shuixin13, 4.1.0,中文,中文參考手冊,犬犬(心帆)"> CSS rel=STYLESHEET>

空間管理和 I/O

12.1 磁碟 I/O 和 raw devices

InnoDB 使用模擬的非同步(simulated asynchronous)的磁碟 I/O來構建 InnoDB：InnoDB 建立許多的 i/o 執行緒來處理 i/o 操作，就如同 read-ahead 一樣。

從 3.23.40b 開始，InnoDB 使用一種被稱為“雙寫 (doublewrite)” 的新穎的檔案轉儲清除(flush)技術。這增加了在操作崩潰或停電後的崩潰修復的性，並因減少了 fsync 操作的必要次數而某些 系統中改善了。

InnoDB 在將頁面寫入一個資料檔案前先將他們寫入到一個相鄰近的表空間中的雙寫(doublewrite)方法被雙寫緩衝(doublewrite buffer)。只有在寫入與轉儲清除(flush)雙寫緩衝結束後，InnoDB 才將頁面寫入到資料檔案的適當的位置。如果在頁面寫入期間崩潰了，InnoDB 將在雙寫緩衝中找出一個完好的副本(copy)來恢復。

從 3.23.41 開始，你也可以使用一個 raw 磁碟分割槽（一個 raw 器件) 作為一個資料檔案。當你建立一個新的資料檔案時你必須在 innodb_data_file_path 設定的資料檔案尺寸後立即加上關鍵詞 newraw 。這個分割槽必須 >= 你所指定的尺寸。注意在 InnoDB 中 1 MB 為 1024 x 1024 bytes，而在磁碟規約中 1 MB 透過為 1000 000 bytes。

innodb_data_home_dir= innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw

　

當你再次啟動系統時，你 必須 將關鍵詞改為 raw。否則 InnoDB 將重寫你的分割槽！從 3.23.44 開始，作為一個安全措施，InnoDB 將阻止修改任何以 newraw 指定的分割槽中的資料。在你增加了一個新的分割槽後，關閉資料庫，修改 my.cnf 檔案，將 newraw 替換為 raw，再重起。

innodb_data_home_dir= innodb_data_file_path=/dev/hdd1:3Graw;/dev/hdd2:2Graw

透過使用一個 raw disk ，在 和某些 Unixes 系統中可以實現無緩衝(non-buffered)的 i/o。

　

在 InnoDB 中有兩個啟發式的(heuristics) read-ahead heuristics ：順序的(sequential) read-ahead 和隨機的(ran) read-ahead。在 sequential read-ahead 中 InnoDB 以順序的方式訪問分割槽中表空間一個片段。因而 InnoDB 將預先以一個批次讀取資料庫頁面到 i/o 系統中。中 random read-ahead 中，InnoDB 將表空間中似乎在程式的有用的某些空間完全讀到緩衝池(buffer pool)內。因而 InnoDB 投遞剩餘地讀到 i/o 系統中。

在檔案中定義的資料檔案形成 InnoDB 的表空間。檔案被簡單地耦合起來形成表空間，在使用中不得被剝離。通常你不能得知你的表所佔用的空間被指定在哪裡， 除非使用下面的事實：在一個新建的表空間中 InnoDB 從檔案的末端開始分配空間。

表空間由預設為 16 KB 的資料庫頁面組成。每 64 個連續的頁面被組成一區域(extent)。表空間內的“檔案(files)”在 InnoDB 中被稱為段(segments)。回滾段(rollback segment)稍微會引起被誤解，因為實際上它在表空間內是由許多個段組成。

InnoDB 中的每個都被分配兩個段(segments)：一個是為了 B-tree 的無葉結點(non-leaf nodes)，另一個是為了葉結點(leaf nodes)。這是為了達到包含資料的葉結點的更好的順序(sequentiality for the leaf nodes)。

當表空間中的一個段增長時，InnoDB 為它個別地分配最初的 32 個頁面。之後 InnoDB 再分配段的整個區域(extents)。InnoDB 會以每次 4 個區域(extents)來增加一個大段以確保資料的良好順序。

表空間中的某些頁面包含其它頁面的點陣圖(bitmaps)，所以在 InnoDB 表空間內的一些區域(extents)不能以一個整體分配給段，而只能作為個體頁面。

當發出一個查詢 SHOW TABLE STATUS FROM ... LIKE ... 來詢問表空間的剩餘空間時，InnoDB 將報告表空間中所有空閒區域(extents)中確實可用的部分。InnoDB 通常會保留一些區域用於 clean-up 和其它的內部目的；這些保留的區域並不包含在剩餘可用空間中。

當從一個表中刪除資料時，InnoDB 將收縮 B-tree 中相應的索引。這是依賴於釋放個別的頁面或區域(extents)以讓其他使用者使用剩餘空間的刪除。 移除(drop)一個表或刪除所有記錄可以保證釋放空間給其他使用者，但是刪除記錄行只有在事務回滾或 consistent read 後並不需要時才會被物理的移除。

如果在一個表的索引內有隨機地插入與刪除，索引將會產生碎片。 碎片的意思是索引頁面在磁碟上的物理順序並不接近於頁面依字母順序排序的記錄， 或分配給索引的 64 個頁面塊中有太多的未使用頁面。如果週期性的透過 mysqldump 將錶轉儲到一個檔案檔案上，移除(drop)表，再從轉儲檔案中過載它，這將提升索引掃描的速度。 另一個碎片整理的辦法就是將表型別改變為 MyISAM 然後再改為 InnoDB 。注意 MyISAM 表在你的作業系統上必須為一個單獨的檔案。

如果索引中的插入總是上升的而總是從後面刪除，那麼 InnoDB 的檔案空間管理演算法可以保證索引中的碎片不會出現。