深度解析Innodb記錄格式源碼
可以通過一個最普遍的插入操作來跟蹤Innodb的記錄格式，因為在插入時，系統得到的是公共的mysql記錄格式record，現在它沒有涉及到任何的存儲引擎，那么這里不管當前這個表對應的存儲引擎是什么，記錄格式是一樣的，對于插入，mysql函數對應的是ha_write_row，具體到Innodb存儲引擎，實際調用的函數是ha_innobase::write_row函數，那么在這里，Innodb首先會將接收到的record記錄轉換為它自己的一個元組tuple，這其實是與record對應的innodb的表示方式，它是一個內存的記錄，邏輯的記錄，那么在系統將其真正的寫入到頁面之前，這條記錄的存在方式都是這個tuple，那么下面主要是從源碼的角度研究Innodb是如何將一個tuple轉換為它的物理的存儲記錄的，主要研究代碼的實現邏輯及記錄的格式。
這里只介紹格式為Compact類型的記錄格式。
實現在某一個頁面插入一個元組（一條記錄）操作的函數是page_cur_tuple_insert，它的參數就是一個dtuple_t*類型的tuple，在這里，它首先要分配一片空間來存儲將要轉換過來的物理記錄，所以這里需要先計算空間的大小，計算方法如下：
1. 首先每條記錄都要包括下面2個部分：REC_N_NEW_EXTRA_BYTES + UT_BITS_IN_BYTES(n_null)，前面表示的是這種格式的固定長度的extra部分，這部分用來存儲什么內容后面會給出，后面表示的是所有字段中哪些字段的值是null，當然這里只存儲那些nullable屬于的字段，如果創建表的時候指定是not null的話，這里就不會被存儲，那么這里是用一個位來表示一個字段的null屬性。那么上面這部分被系統代碼命名為extra_size變量值。
2. 統計每一個列中數據的長度，在統計這個信息的時候，又有多種情況，主要分定長字段和變長字段，對于定長字段，它的長度直接就是數據類型的長度，比如int類型的那就是4個字節，rowid列就是6個字節等，沒有其它附加長度。對于變長字段而言，除了數據內容本身的長度外，還需要計算其數據長度的存儲空間，如果字段的字義長度大于255個字節，或者字段的數據類型為BLOB的，那么需要用2個字節來存儲這個字段的長度；如果定義長度小于128個字節，或者小于256個字節，但類型不是BLOB類型的，那么這個字段的數據長度用一個字節來存儲，除上面2種情況之外，都用2個字節來存儲。那么在這一部分中，用來存儲變長字段數據的長度的空間的長度也是被Innodb計算為extra_size的。
所以現在可以知道，一個innodb的記錄包括2個部分，一部分是extra_size，另一部分是數據內容，那么這2部分的總長度就是上面計算出來的結果，這里把它定義為record_size。
接下來，申請空間，進行元組到記錄的轉換工作。
轉換函數為rec_convert_dtuple_to_rec_new，參數有申請好的記錄空間buf，元組和索引的內存結構。
首先這里有一個操作是rec = buf + extra_size，變量rec表示的是數據內容的存儲開始位置。extra_size就是上面計算出來的2個數據部分。
那么真正執行轉換的是接下來調用的rec_convert_dtuple_to_rec_comp函數，下面是其原型：
- void
- rec_convert_dtuple_to_rec_comp(
- /*===========================*/
- rec_t* rec, /*!< in: origin of record */
- ulint extra, /*!< in: number of bytes to
- reserve between the record
- header and the data payload
- (normally REC_N_NEW_EXTRA_BYTES) */
- const dict_index_t* index, /*!< in: record descriptor */
- ulint status, /*!< in: status bits of the record */
- const dfield_t* fields, /*!< in: array of data fields */
- ulint n_fields)/*!< in: number of data fields */
rec表示的是剛才上面計算出來的rec變量，extra表示的是固定長度的REC_N_NEW_EXTRA_BYTES。
- end = rec;
- nulls = rec - (extra + 1);
- n_null = index->n_nullable;
- lens = nulls - UT_BITS_IN_BYTES(n_null);
- /* clear the SQL-null flags */
- memset(lens + 1, 0, nulls - lens);
在這里，這段代碼一下子很難看明白，那么首先這里畫一下記錄存儲格式：
|---------------------extra_size-----------------------------------------|---------fields_data------------|
|--columns_lens---|---null lens----|------fixed_extrasize(5)------|--col1---|---col2---|---col2----|
那么語句nulls = rec - (extra + 1);得到的結果是什么呢？想干什么？因為extra表示的是REC_N_NEW_EXTRA_BYTES，固定長度的fixed_extrasize，rec表示的是圖中col1的開始位置，那么現在可以知道這條語句的結果就是使得nulls指向了前面nulllens的后一個字節的開始位置。那現在我們知道nulls是一個或者多個字節，用來存儲每一個nullable字段的空標志的，那現在為什么要指向這個數組的后一個字節的開始位置呢？一下子很難想明白，不過從后面的代碼中可以知道，寫入nulls是從后面向前面寫的，所以這也理解了為什么指向了后面一個字節的位置了。
那接下來的一個語句lens = nulls - UT_BITS_IN_BYTES(n_null);道理也是一樣的，因為columns_lens正好是在nulllens的前面，那么如果向前跳過null標志的所有空間，則指向的位置lens就是columns_lens的后面一個字節的位置了。在寫入值的時候也是從后面向前面寫。
那最后一個語句memset(lens + 1, 0, nulls - lens);表示的意思就很明白了，因為lens指向的是columns_lens的最后一個字節的開始位置，那么加1就指向了nulls空間的開始位置，nulls – lens表示的是nulls空間的長度。這里是將nulls空間清零。
上面有兩個部分都是從后面向前面填寫數據，那是不是擔心在寫入的時候會不會向前面越界呢？其實是不會的，因為這些都是在前面計算好的，extrasize已經是固定的，包括了nulls和columns_lens的長度的。
上面算是初始化工作，下面就是根據每一個字段來填寫record記錄了，下面一段代碼是處理null信息的，對于每一個字段，都會做下面的處理：
- if (!(dtype_get_prtype(type) & DATA_NOT_NULL)) {
- /* nullable field */
- ut_ad(n_null--);
- if (UNIV_UNLIKELY(!(byte) null_mask)) {
- nulls--;
- null_mask = 1;
- }
- ut_ad(*nulls < null_mask);
- if (dfield_is_null(field)) {
- *nulls |= null_mask;
- null_mask <<= 1;
- continue;
- }
- null_mask <<= 1;
- }
從第一行可以看出，要處理這個的條件首先必須是沒有定義not null屬性，所以nulls空間只存儲這些字段的信息。
第4行表示的是如果(byte) null_mask)為0時，nulls向前退一個字節，并且將null_mask恢復為1的初值，因為這個值初始值就是1的，可以猜到，如果這個條件滿足了，則說明已經寫入了8個nullable列了，那么需要移向前一個字節繼續寫null信息了，但發現null_mask是int類型的，而nulls是一個字節一個字節的填的，不匹配啊，不過仔細看，判斷條件是(byte) null_mask)，所以只要寫入8個之后，這個值就為0了。因為對于每一個字段，都是執行null_mask向左移1個位的，所以移8次之后，低8位就都是0了。
第9行表示的是如果這個列的數據就是null值，那么需要將這個null反映到nulls數組中去，因為null_mask當前的值（其實是1的位置）其實表示的是當前nulls這個字節中正在處理的字段的對應關系，也就是說，如果當前的字段的值為null，那么像第10行所示的，將null_mask或到nulls字節上去，如果不為null，就不管，對應的位的值為0。
所以從這里可以看出，整個nulls空間中的位圖是以從后面向前面的順序來表示所有nullable列的null信息的。
- if (fixed_len) {
- } else if (dfield_is_ext(field)) {
- *lens-- = (byte) (len >> 8) | 0xc0;
- *lens-- = (byte) len;
- } else {
- if (len < 128 || (dtype_get_len(type) < 256 && dtype_get_mtype(type) != DATA_BLOB)) {
- *lens-- = (byte) len;
- } else {
- *lens-- = (byte) (len >> 8) | 0x80;
- *lens-- = (byte) len;
- }
- }
- memcpy(end, dfield_get_data(field), len);
- end += len;
從第一行可以看出，對于定長數據，只需要將其數據寫入到記錄里面即可，主要處理的是變長數據，第2行表示的是如果長度大于256個字節，或者數據類型為BLOB，則用兩個字節來存儲其長度，低字節存儲(len >> 8) | 0xc0，高字節存儲(byte) len（被截斷）。其它可以直接看出來。
到13行，是直接將數據拷到數據存儲空間，用end來表示，存儲完一個字段接著下一個字段，是按照索引定義的順序存儲的。
到這里，一條記錄的邏輯到物理的轉換就完成了，從中也知道了Innodb是如何實現其物理記錄的存儲的。
總結：看innodb的代碼，可以說它的代碼非常優美，非常精練的，所以有些地方很難一下子看懂，需要揣測，體會才能深入的理解。同時有很多地方是直接硬編碼的，這樣導致更加難理解，最好的方式是通過宏將其命名，有助于理解。
原文鏈接：http://www.cnblogs.com/bamboos/archive/2013/03/04/2943160.html
【編輯推薦】
