【MySQL篇】内存分配管理机制：全局Buffer Pool与会话级内存分配

💫《博主主页》：
　　　🔎 优快云主页： 奈斯DB
　　　🔎 IF Club社区主页： 奈斯、
　　　🔎 微信公众号： 奈斯DB
🔥《擅长领域》：
　　　🗃️ 数据库：阿里云AnalyticDB (云原生分布式数据仓库)、Oracle、MySQL、SQLserver、NoSQL(Redis)
　　　🛠️ 运维平台与工具：Prometheus监控、DataX离线异构同步工具
💖如果觉得文章对你有所帮助，欢迎点赞收藏加关注💖

    时间一晃2025年已经过去大半，作为国庆前的最后一篇技术分享，今天和各位大佬们深入探讨一个看似基础却至关重要的话题——MySQL数据库启动后的内存分配占用问题。🎯

    有些小伙伴可能认为，数据库上线时只需要配置 innodb_buffer_pool_size 这个参数就万事大吉了，但数据库运行一段时间后内存占用却远超参数的配置。这背后隐藏着怎样的内存分配机制？让我们一探究竟。

    博主记得有一次生产环境告警，内存突然飙升至90%+，排查半天才发现是 sort_buffer_size 配置过大，在高并发连接下产生了 “内存放大效应” 。这就深刻意识到了：每个会话连接都是额外需要占用资源的！

    查阅MySQL 8.0官方文档可以看到，数据库在服务器的内存占用由全局缓冲区和每个连接会话缓冲区共同组成。也就是说，除了我们熟悉的Buffer Pool之外，还有形形色色的内存参数在瓜分着服务器的内存资源。

    那么这篇文章博主将图文并茂地介绍数据库启动后的内存分配占用情况，让各位小伙伴们搞清楚：一个服务器启动MySQL后，这个MySQL实例真真实实的内存分配占用到底是如何构成的。

    废话不多说，开始今天的硬核介绍！ 🚀

---

---

   

一、深入了解内存分配占用机制🔍（内存计算公式）

    根据MySQL 8.0官方文档，内存分配占用的计算公式可以清晰地分为两大板块：

总内存（理论内存最大占用） ≈ 全局缓冲区 + 会话级缓冲区 × 最大连接数

    理论内存最大占用画图说明：

---

    

下面逐个分析两大板块

   

1.1 🏠 全局内存区域（固定占用）：含验证启动后全局内存分配占用

    当MySQL（InnoDB）启动时，会立即申请并占用几乎全部的 innodb_buffer_pool_size 所配置的内存。InnoDB存储引擎的设计初衷是为了追求极致的性能。它在启动时一次性分配整个缓冲池的主要目的在于：

1. 保证内存的连续性和稳定性： 在启动阶段就获得一大块连续的内存空间，可以避免在数据库运行期间，因系统内存碎片化而导致分配失败的问题。
2. 避免运行时开销： 如果采用“按需分配”，那么每当需要新的数据页时，系统都需要执行一次内存分配操作。对于高频的数据库操作来说，这个开销是巨大的。启动时分配消除了这个运行时开销。
3. 初始化开销： 在分配内存后，InnoDB会对缓冲池进行初始化，比如建立LRU链表、设置内存结构等。这个过程在启动时完成，对后续运行的性能影响最小。
4. 虽然原则上是“启动时分配”，但在某些场景下会有细微差异：
   • Linux与延迟分配： 在Linux系统上，由于存在虚拟内存和过度提交机制，操作系统可能会采用“延迟物理分配”的策略。即MySQL进程看到了一块连续的虚拟内存地址空间，但实际的物理内存页，只有在真正被写入（即缓存数据）时，才会由操作系统分配。然而，从大多数监控工具和用户体验上看，这部分内存已经被MySQL进程“占用了”。
   • 大页配置： 如果配置了Linux大页，那么InnoDB必须在启动时就锁定并分配所需的全部大页内存，这是真正的立即物理分配。
        

    当然如果负载压力较大，使用的内存也会超过内存参数设置的值的情况。

innodb_buffer_pool_size    # InnoDB核心缓存池 - 最重要的部分！
+ key_buffer_size          # MyISAM索引缓存（如使用）
+ 其他全局缓冲

   

验证启动后全局内存分配占用：

1. 操作系统监控： 在MySQL启动后，立即使用 top、htop 或 ps 命令查看MySQL进程的内存占用（RES 列），会发现其内存使用量会迅速上升到 (innodb_buffer_pool_size + 其他基础开销) 的水平。
2. InnoDB状态： 使用 SHOW ENGINE INNODB STATUS\G 命令，查看 BUFFER POOL AND MEMORY 部分。其中 Database pages 一行显示的是当前缓冲池中实际缓存的数据页数量。在刚启动时，这个数字很小（甚至为0），但 Buffer pool size 显示的总页数已经达到了配置的值。如下状态说明了，内存已经全部占用，但里面大部分是空的（Free buffers），正等待数据装入。

BUFFER POOL AND MEMORY
----------------------
...
Buffer pool size  393216          # 缓冲池总页数 (单位是16K的页，393216 * 16K = 6GB)
Free buffers      390000          # 空闲页数，启动时很大
Database pages    3216            # 已缓存数据页数，启动时很小
...

   

1.2 👥 每个连接会话内存区域（按连接数倍增）

  只有在有活跃连接会话并执行相关操作时才会分配，没有连接或不需要这些操作时就不会占用内存。分配特点如下：

• 按需分配： 不是连接建立时就分配，而是需要时才分配
• 可能复用： 一个连接在执行多个查询时，可能会复用这些缓冲区
• 独占使用： 每个连接分配自己独立的缓冲区
    

  但实际内存占用 通常远小于这个值，因为：

• 不是所有连接都同时活跃
• 不是所有活跃连接都同时需要这些缓冲区
• 很多连接可能只执行简单查询，不需要排序或大缓冲区

max_connections × (
   sort_buffer_size       # 排序操作缓冲区
   + read_buffer_size     # 顺序扫描缓冲区  
   + binlog_cache_size    # 二进制日志缓存
   + 2MB                  # 线程栈 + 其他连接开销
   + 其他会话级缓存
)

小提示⭐️： 在官网文档的内存计算公式中并没有明确列出每个会话都会分配join_buffer_size、tmp_table_size等按需分配的缓冲区，因此官方公式更像是一个基础模型或保守估算，只会列出几个最常用且默认分配的会话缓冲区。

   

二、内存相关参数介绍

    这篇文章主要是讲解除了配置的全局Buffer Pool参数（innodb_buffer_pool_size）会占用实际配置的内存之外，还有那些内存参数以及会话还会占用额外的内存。因此关于全局Buffer Pool在这篇文章中不做详解的介绍，如下图是官方文档中InnoDB存储引擎架构图，红框中是内存架构，也就是全局Buffer Pool。可以看到全局Buffer Pool由四部分组成，各个部分Buffer的详细介绍，博主以后会专门写一篇去介绍，想要现在就了解全局Buffer Pool组成的可以直接查阅官方文档，InnoDB存储引擎内存架构官方文档链接：17.5 InnoDB In-Memory Structures

参数分类	参数名称	主要作用	配置建议
全局缓冲区	innodb_buffer_pool_size	缓存InnoDB表的数据和索引，是最重要的内存区域	专用服务器可设为物理内存的 50% ~ 75%
	key_buffer_size	缓存MyISAM表的索引（如果使用MyISAM表）	若不使用MyISAM表，可设为 32M 左右
会话/连接级缓冲区	tmp_table_size	控制内存内部临时表的最大大小	建议设置为 64M ~ 256M
	sort_buffer_size	每个连接执行 ORDER BY、GROUP BY、DISTINCT 等需要排序的操作时分配	不宜过大，通常 1M ~ 32M 足够。高并发时需谨慎
	join_buffer_size	每个连接进行表关联查询(JOIN)的连接专属缓冲区	同上，不宜过大，通常 1M ~ 64M 足够
	read_buffer_size	当每个连接需要对MyISAM表进行顺序扫描（全表扫描或范围扫描）时，此缓冲区可以改善性能。对于InnoDB，优化索引和调整 innodb_buffer_pool_size 更有效。	不宜过大，通常 1M ~ 16M ，高并发时需注意
	binlog_cache_size	每个会话（连接）在事务过程中用于缓存二进制日志（binlog）事件的内存大小，事务提交前，binlog事件先写入此缓存 ，如果事务期间生成的事件量超过此缓存大小，MySQL会使用临时磁盘文件。	对于大事务频繁的系统，可考虑设置为 64K ~ 4M
其他配置	max_connections	允许的最大并发连接数	需根据应用需求设定，避免过高导致内存耗尽

配置要点与注意事项：

• 内存分配总原则： MySQL总内存占用 ≈ innodb_buffer_pool_size + key_buffer_size + max_connections × (sort_buffer_size + read_buffer_size + binlog_cache_size + 线程栈 2MB 连接开销)。务必确保总内存使用不超过物理内存，并为操作系统和其他进程预留 2~4GB 空间。
• 核心参数innodb_buffer_pool_size： 这是对性能影响最大的参数。在内存允许的情况下，适当调大此参数，让更多数据和索引缓存在内存中，可以极大减少磁盘I/O，提升性能。从MySQL 5.7版本开始，这个参数支持在线动态调整。
• 谨慎设置连接级参数： sort_buffer_size、join_buffer_size等参数是每个连接独占的。如果设置过大，当并发连接数很高时，总内存消耗会急剧膨胀，可能导致系统内存耗尽。优化的关键不是盲目增大这些参数，而是通过优化SQL和索引来减少其对内存的需求。
• 关于查询缓存： 需要注意的是，在MySQL 8.0及以后版本中，查询缓存(query_cache_size)功能已被移除。在早期版本中，如果查询重复率很低，也建议关闭查询缓存以避免额外的开销。

   

案例：实战计算，看看服务器内存都去哪了

1）假设我们有一个8GB内存的服务器，MySQL相关内存参数配置如下：

[mysqld]
# InnoDB 缓冲池配置
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 8   # 建议每1GB缓冲池对应1个实例，最多64个:cite[10]

# binlog配置
binlog_cache_size = 64K

# 连接与缓存配置
max_connections = 500
table_open_cache = 2000
thread_cache_size = 768

# 排序与临时表配置（注意：这些是每个连接独立的）
sort_buffer_size = 2M
read_buffer_size = 1M
join_buffer_size = 2M
tmp_table_size = 256M

# MyISAM引擎配置
key_buffer_size = 32M

   

2）理论内存最大占用计算：可以看到仅仅是配置参数，理论最大占用就达到6.5G，占用了总内存的81%！😱

固定内存 = 4G + 32M = 4.031G

每连接内存 = (2M + 1M + 64K + 2M) ≈ 5.06M

理论最大占用 = 4.125G + (5.06M × 500) 
          = 4.031G + 2.47G 
          = 6.501G

   

3）连接数的"内存放大效应"🎯

1. 每个连接都是内存的使用者
   • 建立连接时： 分配线程栈 ≈ 2MB
   • 执行排序时： 分配 sort_buffer_size (2MB)
   • 全表扫描时： 分配 read_buffer_size (1MB)
   • 事务操作时： 分配 binlog_cache_size (64K)
2. 最坏情况 vs 实际情况

-- 查看实际连接状态
SHOW STATUS LIKE 'Threads_%';

• Threads_connected： 当前实际连接数（通常远小于max_connections）
• Threads_running： 真正执行查询的线程数（更少！）

  必须按最坏情况规划！ 因为一旦业务高峰来临，所有连接同时执行复杂查询，内存就会瞬间膨胀，甚至OOM（内存耗尽）。
   
   

4）常见陷阱与优化建议⚠️

• 陷阱1：连接级参数配置过大

# ❌ 危险配置（常见误区）
sort_buffer_size = 64M
read_buffer_size = 32M
binlog_cache_size = 8M

# ✅ 推荐配置
sort_buffer_size = 1M ~ 32M
read_buffer_size = 1M ~ 16M
binlog_cache_size = 64K ~ 4M

• 陷阱2：忽略连接池的影响

// 使用连接池时，实际物理连接数远小于应用连接数
// 比如：应用有1000个连接，但数据库连接池只维持50个物理连接
// 这能显著减少内存占用！

• 陷阱3：Buffer Pool设置过小

# ❌ 把内存都分给连接缓冲区
innodb_buffer_pool_size = 2G
# 结果：数据缓存不足，频繁磁盘IO，性能差！

# ✅ 优先保证Buffer Pool
innodb_buffer_pool_size = 物理内存的50%~75%

---

完结。简单总结一下MySQL内存配置：

1. Buffer Pool是核心 - 优先保证
2. 连接数是乘数 - 谨慎配置
3. 会话级参数 - 宜小不宜大

配置前算一算，监控中看一看，让你的MySQL既跑得快又站得稳！