memory引擎在mysql 8.0中未增强，仍存在数据易失、不支持事务/行锁/blob/text、表级锁阻塞高并发、优化器误判等根本性限制，应改用innodb临时表、cte或redis替代。
MEMORY 引擎在 MySQL 8.0 中没有被增强，也没有新特性支持——它仍是旧引擎，且存在根本性限制。如果你发现 MEMORY 表性能不足（比如查询变慢、插入卡顿、OOM 报错），不是调参能解决的，而是该换方案了。
MEMORY 引擎的硬伤在哪？
- 数据只存内存，重启即丢，无法用于持久场景
- 不支持事务、行锁、外键，高并发下容易因表级锁阻塞
-
max_heap_table_size是单表上限，但所有MEMORY表共享这个内存池，超限直接报ERROR 1163 (HY000): Table is full - 没有索引统计信息，优化器常误判执行计划，
EXPLAIN显示type: ALL很常见 - 不支持 BLOB/TEXT，也不支持
JSON字段（哪怕只是存个字符串 ID 映射都受限）
MySQL 8.0 真正可用的替代方案
MEMORY 表通常用来做临时聚合、会话缓存、中间结果暂存——这些需求在 8.0 里有更稳更快的选择：
-
用
TEMPORARY TABLE+InnoDB- 临时表生命周期与会话绑定，数据落盘但速度不差（SSD+
innodb_buffer_pool_size覆盖后基本全内存操作） - 支持索引、事务、行锁，
EXPLAIN可靠，能走覆盖索引 - 示例：
CREATE TEMPORARY TABLE tmp_orders SELECT order_id, user_id FROM orders WHERE status = 1;
- 临时表生命周期与会话绑定，数据落盘但速度不差（SSD+
-
用
CTE（公用表表达式）或窗口函数替代中间表- 避免建表开销，语义清晰，优化器能整体规划执行路径
- 尤其适合“先过滤再排序再分页”类逻辑，
WITH ranked AS (SELECT ..., ROW_NUMBER() OVER (...) rn) SELECT * FROM ranked WHERE rn BETWEEN 101 AND 200;
-
高频读写小数据，改用
Redis或本地进程内缓存-
MEMORY表本质是“数据库里模拟缓存”，而 Redis 的 SET/GET 是微秒级，还带过期、原子操作、集群能力 - 如果只是存用户 session ID → token 映射，MySQL 不该承担这个角色
-
如果非要用 MEMORY，必须关掉的坑
- 别设
max_heap_table_size过大（比如设成 2G），它和tmp_table_size共享同一内存池，容易挤占innodb_buffer_pool - 别在
WHERE里用函数（如WHERE UPPER(name) = 'ABC'），MEMORY不支持函数索引，必然全表扫 - 别依赖
ORDER BY默认有序——MEMORY表无聚簇索引，没ORDER BY就是乱序，且无法用降序索引优化 - 检查
SHOW ENGINE MEMORY STATUS（如果启用了performance_schema），但注意：这个状态不可靠，仅作粗略参考
真正卡点不在参数调优，而在选型。MySQL 8.0 的价值不在修 MEMORY，而在用好 InnoDB 的缓冲池、窗口函数、隐藏索引这些实打实落地的特性。
