今日和一個朋友聊起數據庫，伊很憤憤的說，數據庫不就是一堆文件讀取寫入嗎，我找幾個人幹一年也差不過弄個能用的出來，幹嗎那麼貴。實話說，此話有他的道理，雖然各大數據庫廠商不遺餘力的在自己的產品上疊加無窮無盡的概念，增加無數的噱頭，歸根到底，它所做的就是讀寫文件這麼簡單。但是從另一個方面來講，數據庫的價值在於能夠永遠正確的讀寫文件，不管是在多用戶併發的時候，在出現系統崩潰的時候在，在數據容量超乎想象的巨大的時候，它永遠能夠在可控制的方式下把某個bit，0或者1，持久保存。
研究數據庫如何實現這一點是有趣的。
爲方便討論，本文以SQL Server2005爲例。 假設我們創建一個簡單的數據，沒有添加額外的數據文件，也沒有對數據庫的表建分區。那麼該數據庫的所有表會存到一個文件裏面，我們稱之爲數據文件，當然日誌寫到另外一個。數據文件從物理上講就是一個普通的操作系統文件，但是從邏輯上分成很多個頁，每個頁是連續的8K字節，同時連續的8個頁是數據庫增長的分配單位，稱爲Extent。從更高一層的邏輯上講，屬於同一個Table或Index等數據庫對象的Extent，是一個Allocation Unit。之所以要提到它是因爲在插入新的行時，我們需要在Allocation unit上操作。
相信你已經注意到3個關鍵詞 Page，Extent， Allcation Unit。
Page是數據庫大廈的基本構成模塊，有以下幾類：
- 數據類： 常規數據，溢出數據，大對象數據
- 空閒索引類：空閒頁面索引，全局Extent索引，全局混用extent索引，分配單元Extent索引
- 修改跟蹤類：自從上次backup database發生修改的，backup log發生修改的
這麼多類別的頁面是如何組織在一起的呢。讓我們變身成能看到硬盤數據的小精靈，來參觀數據庫這個城堡，在這裏數據文件是這裏的一個街區。我們看到一條遙遙無盡的馬路邊上，整齊的排着小平房，每個房間寫着Page01,Page02...，每個8個房間之間有一條小道隔開。
第一個房子是紫色的，象徵着至高無上的權利，對，它是獨一無二的，它保存的是整個文件的相關信息。
第二個房子是混合顏色，嗯，它還會變顏色，哦，它是空閒頁面索引頁，它裏面住着8K字節，每個字節描述它管轄範圍內8K房間的飽和狀態，如果都滿了，它就變成黑色。這個房子不是唯一的，每個8K個頁面裏就有他的一個同類。
第三個和第四個房子長的很像，一個是深藍色，一個淺藍色，哦，他們是Extent索引頁，他們裏面的每個bit，64000個哦，每個bit描述它管轄範圍內的一個Extent，3號房管的是專用Extent的，4號管混用Extent的；他們也不是唯一的，沒64000個Extent裏，有它們兄弟的克隆。
第5、6個房子是灰色和黑色，代表主人比較低調。他們是表示其後的64K extent是否發生修改的。他們出現頻率和他們的鄰居一樣。
再後面的個房間是綠色的，他們是真正存放數據的地方，房間裏像抽屜一樣一格一個的。
細看之下發現其中有一些淺紫色的房子。這是分配單元索引的家。它的第一層住着一些byte，告訴我們它管轄哪些Extent，這些Extent都是一個表服務的。它還告訴我們它的一個兄弟在哪裏，它也管着最多64K的extent。它的其他樓層裏住着8K的bit，分別描述它管轄範圍內的Extent的使用情況。
這個時候城市裏突然響起來了廣播： X表搬來了新的住戶，請負責安置。
正在一愣之間，看見一道身影掠過，徑直跑到一個淺綠的房前：喂，是你們表吧，找個空閒頁面安置一下。
好，我看看，哎呀，我這裏已經注滿了，給我我兄弟的住址，你去問問它吧？
可是它兄弟也注滿了。
身影跑到藍色的房子那裏，嘿，X表需要空間，您幫着找個空閒的Extent吧；
兩兄弟異口同聲的說，好，嗯，35499號Extent還有空閒的頁面給X表吧；
就這樣一個新的房間被佔用了。細看35499號extent，它住着好幾個表的Page，原來這是個臨時居住地，各個表混住的。
突然，X表的IAM站起來說，我們表在臨時居住區的Page已經達到8個了，請分配給我們一個專用Extent，我們不希望和別的表發生衝突。
藍色兄弟說，好，36700好extent專門給你們了，你的Page趕快搬走吧。
嗯，我要吃飯去了，再見。。。
