MySQL-37：記憶體臨時表

37.1 臨時表的組織結構

InnoDB引擎： B+樹方式的組織結構，前面是索引，節點是索引+資料，節點是有序的。

Memory引擎： 索引是hash索引，陣列以陣列的方式存放，先來先插入到結尾，陣列中有空洞，則下次的資料插入會補到該位置，陣列中資料是無序，索引也是無序的。

從上可見Memory引擎和InnoDB引擎的組織結構是不一樣的：

• Memory引擎採用資料和索引分開存放
• InnoDB引擎採用索引組織表的形式

Memory引擎和InnoDB引擎的不同點：

• 資料和索引的組織方式
• 當資料出現空洞，因為是否有序決定插入資料時是否需要大變動
• 資料位置發生變化的時候，InnoDB 表只需要修改主鍵索引，而記憶體表需要修改所有索引；

Memory引擎需要做範圍查詢的時候，它用不上索引，因為是無序的，需要走全表掃描。

37.2 索引

我們通過給Memory引擎下的資料新增B+數索引，可以達到目的，新增索引的效果如下：

我們通過如下語句：

alter table t add index a_btree_index using btree (id);

當出現訪問訪問時，它會自動走B+樹索引。

37.3 Memory 臨時表的問題

鎖粒度問題：

記憶體表只支援表級鎖，索引在事務併發的支援上會很低效，因為一旦有事務獲取了該鎖，就會導致整張表鎖住。

資料持久化問題：

資料存放到記憶體中，如果資料庫異常重啟，就會導致所有的記憶體表清空。當資料庫重啟回來，他會在binlog中寫入delete from t，以此來達到操作與記錄一致的情況。

但是在兩個庫互為主備庫的情況下，備庫異常重啟，binlog同步到主庫，會導致主庫的記憶體表莫名其妙的消失。