1、緩存池 buffer pool緩存池是InnoDB在內存中開辟的用來緩存表數據和索引數據的區域，一般 可以設置為50%~80%的物理內存大小，通過對經常訪問的數據放置到內存當中來加快訪 問速度。 Buffer pool以page頁的格式組成，頁之間組成list列表，并通過LRU算法（最近最少使用算法）對長久不使用的頁進行置換。 數據的讀寫需要經過緩存（緩存在buffer pool 即在內存中） 數據以整頁（16K）位單位讀取到緩存中 緩存中的數據以LRU策略換出（最少使用策略） IO效率高，性能好 2、Adaptive Hash Index（自適應哈希索引） Adaptive Hash index屬性使得InnoDB更像是內存數據庫。該屬性通過innodb_adapitve_hash_index開啟，也可以通過—skip-innodb_adaptive_hash_index參數關閉 InnoDB存儲引擎會監控對表上索引的查找，如果觀察到建立哈希索引可以帶來速度的提升，則建立哈希索引，所以稱之為自適應（adaptive） 的。自適應哈希索引通過緩沖池的B+樹構造而來，因此建立的速度很快。而且不需要將整個表都建哈希索引，InnoDB存儲引擎會自動根據訪問的頻率和模式 來為某些頁建立哈希索引。 哈希（hash）是一種非常快的等值查找方法，在一般情況下這種查找的時間復雜度為O(1),即一般僅需要一次查找就能定位數據。 innodb會監控對表上個索引頁的查詢。如果觀察到建立哈希索引可以帶來速度提升，則自動建立哈希索引 AHI，是數據庫自動優化的 3、Redo log buffer Redo log buffer是一塊用來存放寫入redo log文件內容的內存區域，內存的大小由innodb_log_buffer_size參數確定。該buffer的內容會定期刷新到磁盤的redo log文件中。 參數innodb_flush_log_at_trx_commit決定了刷新到文件的方式，參數innodb_flush_log_at_timeout參數決定了刷新的頻率。 4、系統表空間 InnoDB的系統表空間用來存放表和索引數據，同時也是doublewriter緩存，change緩存和回滾日志的存儲空間，系統表空間是被多個表共享的表空間。 默認情況下，系統表空間只有一個系統數據文件，名為ibdata1。系統數據文件的位置和個數由參數innodb_data_file_path參數決定。 5、Doublewrite緩存 Doublewrite緩存是位于系統表空間的存儲區域，用來緩存InnoDB的數據頁從innodb buffer pool中flush之后并寫入到數據文件之前，所以當操作系統或者數據庫進程在數據頁寫磁盤的過程中崩潰，Innodb可以在doublewrite緩存中找到數據頁的備份而用來執行crash恢復。 數據頁寫入到doublewrite緩存的動作所需要的IO消耗要小于寫入到數據文件的消耗，因為此寫入操作會以一次大的連續塊的方式寫入。 doublewrite組成： 內存中的doublewrite buffer,大小2M， 物理磁盤上共享表空間中連續的128個頁，即2個區（extend），大小同樣為2M。 對緩沖池的臟頁進行刷新時，不是直接寫磁盤，而是會通過memcpy()函數將臟頁先復制到內存中的doublewrite buffer，之后通過doublewrite 再分兩次，每次1M順序地寫入共享表空間的物理磁盤上，在這個過程中，因為doublewrite頁是連續的，因此這個過程是順序寫的，開銷并不是很大。在完成doublewrite頁的寫入后，再將doublewrite buffer 中的頁寫入各個 表空間文件中，此時的寫入則是離散的。如果操作系統在將頁寫入磁盤的過程中發生了崩潰，在恢復過程中，innodb可以從共享表空間中的doublewrite中找到該頁的一個副本，將其復制到表空間文件，再應用重做日志。  6、Undo日志 Undo日志是由一系列事務的undo日志記錄組成，每一條undo日志記錄包含了事務數據回滾的相關原始信息，所以當其它的事務需要查看修改前的原始數據，則會從此undo日志記錄中獲取。Undo日志存放在回滾段中的undo日志段中。默認情況下回滾段是作為系統表空間的一部分，但也可以有自己獨立的undo表空間，通過設置innodb_undo_tablespaces和innodb_undo_directory兩個參數。 Innodb支持最大128個回滾段，其中的32個用來服務臨時表的相關事務操作，剩下的96個服務非臨時表，每個回滾段可以同時支持1023個數據修改事務，也就是總共96K個數據修改事務。 Innodb_undo_logs參數用來設置回滾段的個數。 Undo Log的原理很簡單，為了滿足事務的原子性，在操作任何數據之前，首先將數據備份到一個地方（這個存儲數據備份的地方稱為Undo Log）。然后進行數據的修改。如果出現了錯誤或者用戶執行了ROLLBACK語句，系統可以利用Undo Log中的備份將數據恢復到事務開始之前的狀態 7、File-per-table表空間 File-per-table表空間意味著innodb的數據表不是共享一個系統表空間，而是每個表一個獨立的表空間。可以通過設置innodb_file_per_table開啟此屬性。開啟之后每個表數據和索引數據都會默認單獨存放在數據文件夾下的.ibd數據文件中。默認是開啟的。 show variables like '%per_table%'; set global innodb_file_per_table=off; ###關閉 8、temporary表空間 temporary臨時表空間用來存放臨時表，默認情況下是在數據文件夾下的ibtmp1數據文件，此數據文件被設置為每次自動增長12MB大小，當然也可以設置innodb_temp_data_file_path來指定臨時表空間文件的存放位置。 臨時表空間文件在正常的shutdown之后會自動清除，但在crash發生時不會清除，這就需要DBA手動去刪除表空間文件或重啟服務器。 show variables like '%innodb_temp%'; 如果發現臨時表空間數據文件比較大，可以考慮重啟MySQL來釋放空間大小。 9、redo log redo日志是存在于磁盤上的文件，包括ib_logfile0和ib_logfile1兩個文件，常用于在crash恢復發生時將還沒來得及寫入到數據文件中但已經完成提交的事務在數據庫初始化時重新執行一遍。 InnoDB對redo log buffer寫入到redo log文件的方式提供了組提交(group commit)的方式，意味著針對一次寫磁盤操作可以包含多個事務數據，用此方法提高性能。 為了IO效率，數據庫修改的文件都在內存緩存中完成的； 如果宕機了則：應用已經持久化好了的日志文件，讀取日志文件中沒有被持久化到數據文件里面的記錄；將這些記錄重新持久化到我們的數據文件中 innodb日志持久化相關參數 innodb_flush_log_at_trx_commit 0：每秒寫入并持久化一次（不安全，性能高，無論mysql或服務器宕機，都會丟數據最多1秒的數據） 1：每次commit都持久化（安全，性能低，IO負擔重） 2：每次commit都寫入內存的內存緩存，每秒再刷新到磁盤（安全，性能折中，mysql宕機數據不會丟失，服務器宕機數據會丟失最多1秒的數據） innodb_flush_log_at_timeout參數決定最多丟失多少秒的數據，默認是1秒