## 表定義 MySQL的表包含表名，表空間、索引、列、約束等信息，這些表的元數據我們暫且稱為表定義信息。 對于InnoDB來說，MySQL在server層和engine層都有表定義信息。server層的表定義記錄在frm文件中，而InnoDB層的表定義信息存儲在InnoDB系統表中。例如: ~~~ InnoDB_SYS_DATAFILES InnoDB_SYS_TABLESTATS InnoDB_SYS_INDEXES InnoDB_SYS_FIELDS InnoDB_SYS_TABLESPACES InnoDB_SYS_FOREIGN_COLS InnoDB_SYS_FOREIGN InnoDB_SYS_TABLES InnoDB_SYS_COLUMNS ~~~ 注：以上都是memory表，它們內容是從實際系統表中獲取的。實際上InnoDB系統表engine也是InnoDB類型的，數據也是以B樹組織的。 在數據庫每次執行sql都會訪問表定義信息，如果每次都從frm文件或系統表中獲取，效率會較低。因此MySQL在server層和InnoDB層都有表定義的緩存。以MySQL 5.6為例，參數table_definition_cache控制了表定義緩存中表的個數，server層和InnoDB層的表定義緩存共用此參數。 ## server層表定義緩存 server層表定義為TABLE_SHARE對象，TABLE_SHARE對象有引用計數和版本信息，每次使用flush操作會遞增版本信息。 server層表定義緩存由hash表和old_unused_share鏈表組成，通過hash表table_def_cache以表名為key緩存TABLE_SHARE對象，同時未使用的TABLE_SHARE對象通過old_unused_share鏈表鏈接。 * 獲取TABLE_SHARE(`get_table_share`) 先從HASH查找，找不到再讀取frm文件加載表定義信息。同時遞增引用計數。 * 釋放TABLE_SHARE(`release_table_share`) 遞減引用計數。當引用計數為0時，如果版本發生變化，直接刪除此TABLE_SHARE。 old_unused_share鏈表調整: * 獲取TABLE_SHARE時(`get_table_share`) 未使用的TABLE_SHARE對象被啟用，須從LRU鏈表取出； 如果緩存總數超出table_definition_cache大小，須依次從old_unused_share鏈表尾部去除。 * 釋放TABLE_SHARE時(`release_table_share`) 當引用計數為0時，如果版本沒有發生變化，將TABLE_SHARE對象加入old_unused_share鏈表尾部。如果緩存總數超出table_definition_cache大小，須依次從old_unused_share鏈表尾部去除。 真正free TABLE_SHARE對象時，如果此對象還在old_unused_share鏈表中，須從其中去除。 ## InnoDB層表定義緩存 InnoDB表定義為`dict_table_t`， 緩存為`dict_sys_t`，結構如下 ~~~ struct dict_sys_t{ ... hash_table_t* table_hash; /*!< hash table of the tables， based on name */ hash_table_t* table_id_hash; /*!< hash table of the tables， based on id */ ulint size; /*!< varying space in bytes occupied by the data dictionary table and index objects */ dict_table_t* sys_tables; /*!< SYS_TABLES table */ dict_table_t* sys_columns; /*!< SYS_COLUMNS table */ dict_table_t* sys_indexes; /*!< SYS_INDEXES table */ dict_table_t* sys_fields; /*!< SYS_FIELDS table */ UT_LIST_BASE_NODE_T(dict_table_t) table_LRU; /*!< List of tables that can be evicted from the cache */ UT_LIST_BASE_NODE_T(dict_table_t) table_non_LRU; /*!< List of tables that can't be evicted from the cache */ }; ~~~ 主要由hash表和LRU鏈表組成。 * 兩個hash表，分別按name和id，便于按name和id進行查找。 * table_non_LRU： 存放不放入到LRU鏈表的表，這些表不會從緩存中淘汰出去。那么哪些表會放入table_non_LRU鏈表呢？ 1. 系統表，如sys_tables sys_columns sys_fields SYS_INDEXES等； 2. 有引用關系的表都加入table_non_LRU(dict_foreign_add_to_cache)； 3. 有全文索引的表都加入table_non_LRU(fts_optimize_add_table)； 4. 便于刪表，刪表前對將表加入table_non_LRU，刪表時加載表時保證表仍然在緩存中，例如表corrupted時。 * table_LRU 不在table_non_LRU鏈表中的表都加入table_LRU鏈表中。 * dict_table_t* sys_tables 等 常用系統表單獨標識出來，每次使用時直接取出，不需要從hash表查找。 * LRU的維護 既然存在table_LRU鏈表，我們就需要考慮LRU的調整： 1. 將最近使用的表放入LRU頭部（`dict_move_to_mru`） 每次按name和id查找時都會調整，參考`dict_table_open_on_name`和`dict_table_open_on_id`。 2. LRU的淘汰 * 淘汰哪些表 LRU中表才可以淘汰，table_non_LRU中的表不參入淘汰。 表引用計數必須為0(`table->n_ref_count == 0`)。 表的索引被自適應哈希引用計數必須為0(`btr_search_t->ref_count=0`)。 * 何時淘汰 主線程控制每47（SRV_MASTER_DICT_LRU_INTERVAL）秒檢查一次，只遍歷一半LRU鏈表。 主線程空閑時檢查一次，但掃所有LRU鏈表，清理控制緩存表個數不能超過table_definition_cache。 * 如何淘汰 從LRU尾部開始，淘汰滿足條件表(`dict_make_room_in_cache`)。 注： 1\. table_non_LRU沒有實際作用，主要用于debug； 2\. 如果有較多引用約束的表，它們不受LRU管理，參數table_definition_cache的作用會弱化。