Carry の Blog Carry の Blog
首页
关于
  • Hermes Agent 平台
  • Claude Code
  • OpenClaw
  • GPU 推理节点运维
  • MySQL 运维知识地图
  • Elasticsearch 运维知识地图
  • Redis 运维知识地图
  • TiDB 体系
  • DBA 常用 SQL 与命令
  • Nginx 运维知识地图
  • Prometheus 监控
  • Docker
  • Systemd
  • Iptables
  • Firewalld
  • Sshd
  • MySQL8 运维 SOP 手册
  • MySQL 实战 45 讲(读书笔记)
  • 分类
  • 标签
  • 归档
GitHub (opens new window)

Carry の Blog

好记性不如烂键盘
首页
关于
  • Hermes Agent 平台
  • Claude Code
  • OpenClaw
  • GPU 推理节点运维
  • MySQL 运维知识地图
  • Elasticsearch 运维知识地图
  • Redis 运维知识地图
  • TiDB 体系
  • DBA 常用 SQL 与命令
  • Nginx 运维知识地图
  • Prometheus 监控
  • Docker
  • Systemd
  • Iptables
  • Firewalld
  • Sshd
  • MySQL8 运维 SOP 手册
  • MySQL 实战 45 讲(读书笔记)
  • 分类
  • 标签
  • 归档
GitHub (opens new window)
  • MySQL8-SOP

    • 第一章 概述
    • 第二章 环境准备
    • 第三章 安装部署规范
    • 第四章 ReplicaSet高可用配置
    • 第五章 监控与日常维护
    • 第六章 故障处理手册
    • 第七章 安全与权限管理
    • 第八章 扩展与升级方案
    • 附录
  • 课程笔记

  • 专题系列
  • 课程笔记
  • MySQL实战45讲
Carry の Blog
2024-07-27
目录

Memory引擎详解

# Memory引擎详解

Memory引擎(也称为HEAP引擎)是MySQL中一个特殊的存储引擎,它将所有数据存储在内存中,具有高速访问的特点。本文将详细介绍Memory引擎的特性和使用场景。

# 1. Memory引擎概述

Memory引擎是MySQL中唯一一个将所有数据存储在内存中的存储引擎。它具有以下特点:

  • 所有数据都存储在内存中,访问速度极快
  • 数据在数据库重启后会丢失
  • 支持索引,包括B-tree索引和哈希索引
  • 不支持事务和外键约束
  • 适用于临时数据存储和高速缓存场景

# 2. Memory引擎的适用场景

# 2.1 临时表

Memory引擎最适合用于创建临时表,特别是在需要快速访问数据的场景中。例如:

CREATE TEMPORARY TABLE temp_table (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    value INT
) ENGINE=MEMORY;
1
2
3
4
5

# 2.2 缓存表

对于一些经常查询但不需要持久化的数据,可以使用Memory引擎来提高访问速度:

CREATE TABLE cache_table (
    key_field VARCHAR(100) PRIMARY KEY,
    value_field TEXT,
    expire_time TIMESTAMP
) ENGINE=MEMORY;
1
2
3
4
5

# 2.3 会话状态存储

在Web应用中,可以使用Memory引擎来存储用户会话信息:

CREATE TABLE session_data (
    session_id CHAR(32) PRIMARY KEY,
    user_id INT,
    data TEXT,
    last_access TIMESTAMP
) ENGINE=MEMORY;
1
2
3
4
5
6

# 3. Memory引擎的限制和注意事项

# 3.1 内存限制

Memory引擎的数据完全存储在内存中,因此受到系统内存的限制。当内存不足时,可能会导致数据无法正常存储。

# 3.2 数据持久性

由于Memory引擎将数据存储在内存中,数据库重启后所有数据都会丢失。因此不适合存储重要数据。

# 3.3 索引类型

Memory引擎支持B-tree索引和哈希索引。哈希索引适用于等值查询,B-tree索引适用于范围查询。

-- 哈希索引示例
CREATE TABLE hash_index_table (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    INDEX(name) USING HASH
) ENGINE=MEMORY;

-- B-tree索引示例
CREATE TABLE btree_index_table (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    INDEX(name) USING BTREE
) ENGINE=MEMORY;
1
2
3
4
5
6
7
8
9
10
11
12
13

# 3.4 字符集限制

Memory引擎不支持TEXT和BLOB类型的字段,只能使用VARCHAR、CHAR等字符类型。

# 4. Memory引擎与其他存储引擎对比

特性 Memory引擎 MyISAM InnoDB
存储位置 内存 磁盘 磁盘
数据持久性 不持久 持久 持久
事务支持 不支持 不支持 支持
锁机制 表级锁 表级锁 行级锁
外键支持 不支持 不支持 支持

# 5. 性能优化建议

# 5.1 合理设置内存参数

-- 查看Memory引擎相关参数
SHOW VARIABLES LIKE 'tmp_table_size';
SHOW VARIABLES LIKE 'max_heap_table_size';
1
2
3

# 5.2 选择合适的索引类型

根据查询模式选择合适的索引类型:

-- 如果主要进行等值查询,使用哈希索引
CREATE TABLE test_table (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    INDEX(name) USING HASH
) ENGINE=MEMORY;

-- 如果需要范围查询,使用B-tree索引
CREATE TABLE test_table (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    INDEX(name) USING BTREE
) ENGINE=MEMORY;
1
2
3
4
5
6
7
8
9
10
11
12
13

# 6. 实际应用示例

# 6.1 创建一个缓存表

CREATE TABLE product_cache (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(100),
    price DECIMAL(10,2),
    category VARCHAR(50),
    last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=MEMORY;

-- 插入数据
INSERT INTO product_cache VALUES 
(1, 'iPhone 12', 6999.00, '手机', NOW()),
(2, 'MacBook Pro', 12999.00, '电脑', NOW());

-- 查询数据
SELECT * FROM product_cache WHERE product_id = 1;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 6.2 使用Memory引擎创建临时结果表

-- 创建临时表用于复杂查询的结果缓存
CREATE TEMPORARY TABLE temp_sales_summary (
    product_id INT,
    total_sales DECIMAL(12,2),
    sales_count INT,
    INDEX(product_id)
) ENGINE=MEMORY;

-- 执行复杂查询并将结果存储到临时表
INSERT INTO temp_sales_summary
SELECT product_id, SUM(amount), COUNT(*) 
FROM sales 
GROUP BY product_id;

-- 使用临时表进行后续查询
SELECT * FROM temp_sales_summary WHERE total_sales > 10000;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 7. 总结

Memory引擎虽然有诸多限制,但在特定场景下仍然非常有用。它特别适合用于:

  1. 临时数据存储
  2. 高速缓存
  3. 会话状态管理
  4. 临时查询结果缓存

使用Memory引擎时需要特别注意数据的持久性问题,确保不会影响业务的稳定性。

#学习笔记#MySQL
上次更新: 8/29/2026
最近更新
01
当监控说没事而 DMV 说有事——N9E 与 SQL Server 指标交叉验证实战 原创
08-28
02
TiKV 节点 CPU 周期性打满,进程却只占 4%:一次热点 Region 的逆向排查 原创
08-28
03
托管 SQL Server 的运维边界:哪些 DBA 手段会失效,以及用什么替代 原创
08-28
更多文章>
Theme by Vdoing
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式