文件系統存儲特點
稱HEAP存儲引擎凿滤，所以數據保存在內存中（服務器重啟則表的數據丟失锋喜，但是表結構是保留的着茸，表結構保存在磁盤文件中，而表的內容是存儲在內存中）
功能特點
- 支持HASH索引（等值查詢）和BTree索引（范圍查找）（默認HASH）
- 所有字段都為固定長度varchar(10) = char(10)
- 不支持BLOG和TEXT等大字段
- Memory存儲引擎使用表級鎖
- 表的最大大小由max_heap_table_size參數決定（默認16M漱竖，對存在的表修改是無效的）
實例
首先創(chuàng)建表
MySQL [test]> create table mymemory (id int,c1 varchar(10),c2 char(10),c3 text ) engine = memory;
ERROR 1163 (42000): The used table type doesn't support BLOB/TEXT columns
MySQL [test]> create table mymemory (id int,c1 varchar(10),c2 char(10) ) engine = memory;
Query OK, 0 rows affected (0.02 sec)
我們能夠看到，表是不支持TEXT字段的
我們再看下文件系統
[root@wangerxiao test]# ls -lh mymemo*
-rw-r----- 1 mysql mysql 8.5K Mar 17 15:25 mymemory.frm
只有一個保存表結構的文件
下面我們再看下表的索引
首先，新建兩個索引
MySQL [test]> create index idx_c1 on mymemory(c1);
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
MySQL [test]> create index idx_c2 using btree on mymemory(c2);
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
我們查看當前索引類型
MySQL [test]> show index from mymemory \G
*************************** 1. row ***************************
Table: mymemory
Non_unique: 1
Key_name: idx_c1
Seq_in_index: 1
Column_name: c1
Collation: NULL
Cardinality: 0
Sub_part: NULL
Packed: NULL
Null: YES
Index_type: HASH
Comment:
Index_comment:
*************************** 2. row ***************************
Table: mymemory
Non_unique: 1
Key_name: idx_c2
Seq_in_index: 1
Column_name: c2
Collation: A
Cardinality: NULL
Sub_part: NULL
Packed: NULL
Null: YES
Index_type: BTREE
Comment:
Index_comment:
2 rows in set (0.00 sec)
存在兩個索引，一個為默認的屉凯，一個是指定的BTree。
接下來我們查看表的狀態(tài)
MySQL [test]> show table status like 'mymemory'\G
*************************** 1. row ***************************
Name: mymemory
Engine: MEMORY
Version: 10
Row_format: Fixed
Rows: 0
Avg_row_length: 86
Data_length: 0
Max_data_length: 7799082
Index_length: 0
Data_free: 0
Auto_increment: NULL
Create_time: 2017-03-17 15:30:16
Update_time: NULL
Check_time: NULL
Collation: utf8mb4_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)
Memory存儲引擎表和臨時表的區(qū)別
臨時表分兩類：系統使用臨時表芬探，create temporary table 建立的臨時表神得。無論哪種表厘惦，只有當前session是可見的偷仿。而Memory表是所有線程都可以使用的。
系統使用臨時表又分為兩類：查過限制使用Myisam臨時表宵蕉，未超過限制使用Memory表酝静。
使用場景
- 用于查找或者是映射表，例如郵編和地區(qū)的對應表
- 用于保存數據分析中產生的中間表
- 用于緩存周期性聚合數據的結果表
注意一點是：Memory數據易丟失羡玛，所以要求數據可再生
memory存儲引擎是MySQL中的一類特殊的存儲引擎别智。其使用存儲在內存中的內容來創(chuàng)建表，而且所有數據也放在內存中稼稿。這些特性都與InnoDB薄榛，MyISAM存儲引擎不同。
OK让歼，這里我們講解一些memory存儲引擎的文件存儲形式敞恋，索引類型，存儲周期和優(yōu)缺點谋右。
每個基于memory存儲引擎的表實際對應一個磁盤文件硬猫，該文件的文件名與表名相同，類型為frm類型。該文件只存儲表的結構啸蜜，而其數據文件坑雅，都是存儲在內存中的，這樣有利于對數據的快速的處理衬横，提高整個表的處理效率裹粤。
值得注意的是：服務器需要有足夠的內存來維持memory存儲引擎的表的使用。如果不需要了蜂林，可以釋放這些內存蛹尝，甚至可以刪除不需要的表。
Memory存儲引擎默認使用哈希(HASH)索引悉尾，其速度比使用B型樹(BTREE)索引快突那。如果我們需要使用B型樹索引，可以在創(chuàng)建索引時選擇使用构眯。
這里來整理一個小的技巧：
Memory存儲引擎通常很少用到愕难，至少我是沒有用到過。因為Memory表的所有數據都是存儲在內存上的惫霸，如果內存出現異常會影響到數據的完整性猫缭。
如果重啟機器或者關機，表中的所有數據都將消失壹店，因此猜丹，基于Memory存儲引擎的表的生命周期都比較短，一般都是一次性的硅卢。
Memory表的大小是受到限制的射窒，表的大小主要取決于2個參數，分別是max_rows和max_heap_table_size将塑。其中脉顿，max_rows可以在創(chuàng)建表時指定，max_heap_table_size的大小默認為16MB点寥，可以按需要進行擴大艾疟。
因此，其基于內存中的特性敢辩，這類表的處理速度會非潮卫常快，但是戚长，其數據易丟失盗冷，生命周期短±穑基于其這個缺陷正塌，選擇Memory存儲引擎時需要特別小心嘀略。
