memory表数据重启即丢，因其仅将数据和索引存储在ram中，不写磁盘，服务停止则内存清空，属设计特性而非bug，适用于临时缓存或中间计算，不可用于持久化。
MEMORY表数据重启即丢，是因为它只存内存
MySQL的MEMORY存储引擎不写磁盘，所有数据都保留在RAM里。服务一停，内存清空，数据就没了——这不是bug，是设计使然。它适合做临时缓存、中间计算结果或会话级暂存表，但绝不能当持久化表用。
-
MEMORY表在CREATE TABLE时若未显式指定ENGINE=MEMORY，默认不会自动启用；一旦用了，就要清楚它没有崩溃恢复能力 - 即使设置了
max_heap_table_size和tmp_table_size，也只是限制单表/临时表大小，不影响“重启必丢”这个本质 -
SELECT ... INTO OUTFILE或INSERT INTO ... SELECT从MEMORY表导出数据，必须在重启前手动执行，否则无从补救
误用MEMORY表导致“重启后数据消失”，怎么快速识别
如果你发现某张表每次重启MySQL后都空了，先查它的引擎类型：
SHOW CREATE TABLE `your_table_name`;
如果输出中包含ENGINE=MEMORY，基本可以锁定原因。再确认是否有人在初始化脚本里写了类似：
CREATE TABLE tmp_user_stats AS SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;
这种语句默认用MyISAM（旧版）或InnoDB（新版），但若显式加了ENGINE=MEMORY，就踩坑了。
- 不要依赖
SHOW TABLE STATUS里的Rows字段判断数据是否还在——MEMORY表可能显示行数，但服务重启后该值归零且不可逆 -
information_schema.TABLES中ENGINE列是唯一可靠来源，别信应用层缓存或业务日志里的“已插入”记录 - 如果表名带
tmp_、cache_、session_等前缀，优先检查是否被误设为MEMORY
想保留数据又需要内存速度？替代方案不是换参数，而是换引擎
没有“让MEMORY变持久”的配置项。真要兼顾性能与可靠性，得换思路：
- 用
InnoDB+ 足够大的innodb_buffer_pool_size：热数据常驻内存，读写依然快，且有redo log保障崩溃安全 - 用
TEMPORARY TABLE（非MEMORY）：会话级临时表，自动清理，不跨连接，比MEMORY更可控 - 外部缓存如Redis：把高频读、低一致性要求的数据放Redis，MySQL只存权威源，解耦更干净
- 如果硬要“内存加速”，考虑
query_cache_type=0关掉过时的查询缓存，改用应用层主动缓存，避免引擎层陷阱
最常被忽略的一点：MEMORY表的索引也全在内存里
不只是数据，MEMORY表的所有BTREE或HASH索引都随进程消亡而消失。这意味着：
- 重启后首次
SELECT会触发全表扫描，因为索引没了——哪怕表只有1万行，也可能卡顿 -
HASH索引不支持范围查询（>、BETWEEN），但很多人建了还照着范围条件写SQL，实际走不了索引 - 没设
PRIMARY KEY的MEMORY表，UPDATE/DELETE性能会断崖下跌，因为找不到高效定位方式
真正要用MEMORY，就得接受它是一次性、会失效、需重建的工具。任何把它当主力存储的尝试，最后都会在某次重启时暴露出来。
