MySQL 服务器内存碎片：成因、检测与内存持续增长的解决策略

在 MySQL 运维中，“内存持续增长” 是常见且隐蔽的性能隐患 —— 部分服务器初始内存占用仅 2GB，运行数月后却飙升至 8GB 以上，且无明显大查询或高并发负载，重启后内存可暂时回落，但不久后又会再次增长。这种 “无理由的内存膨胀”，多数源于内存碎片的累积。MySQL 内存碎片并非 “无效内存”，而是内存分配与释放过程中产生的 “碎片化空闲空间”，这些空间无法被有效复用，导致 MySQL 被迫申请更多物理内存，最终引发系统 OOM（内存溢出）或性能下降。本文将从碎片本质、成因、检测到解决，全面解析 MySQL 内存碎片问题，帮助读者根治内存持续增长的痛点。

一、基础认知：MySQL 内存碎片的本质与危害

要解决内存碎片问题，需先明确 “什么是 MySQL 内存碎片”“它为何会导致内存持续增长”—— 这是后续分析的基础。

1. 内存碎片的定义：“能用但用不上” 的空闲空间

内存碎片是内存分配器（如 glibc、tcmalloc、jemalloc）在 “分配 - 释放” 循环中产生的不连续空闲内存块。这些空闲块总量足够，但因 “地址不连续” 或 “块大小不匹配请求尺寸”，无法被 MySQL 后续的内存申请复用，导致：

• MySQL 需要向操作系统申请新的物理内存以满足需求；

• 已分配的内存中存在大量 “空闲碎片”，但无法释放（因碎片与活跃内存块交织），形成 “内存占用持续增长但实际利用率低” 的矛盾。

MySQL 的内存碎片与操作系统内存碎片的核心区别：

• 操作系统碎片：针对物理内存（如 Linux 的页框），需通过内存交换（Swap）或压缩缓解；

• MySQL 内存碎片：针对用户态内存（MySQL 进程内的堆内存），由 MySQL 的内存分配逻辑与分配器特性共同决定，需从 MySQL 配置与分配器优化入手解决。

2. 内存碎片导致内存持续增长的危害

内存碎片的累积并非 “无害”，其对 MySQL 服务器的影响会随时间逐步加剧：

• 系统资源浪费：空闲碎片占用物理内存，导致其他进程（如监控、备份工具）可用内存减少，甚至触发系统 OOM Killer 杀死 MySQL 进程；

• 性能隐性下降：内存碎片会增加内存分配器的 “寻块开销”（需遍历空闲块链表寻找匹配尺寸的空间），导致 MySQL 执行 SQL 时的内存申请延迟增加（尤其高并发场景）；

• 运维风险升高：内存持续增长会迫使运维人员频繁重启 MySQL 以释放内存，中断业务连续性；若未及时处理，最终会因内存耗尽导致服务宕机。

二、核心成因：MySQL 中内存碎片产生的 5 大典型场景

MySQL 内存碎片的产生并非偶然，而是与 “内存分配机制”“参数配置”“业务操作” 深度绑定，以下 5 个场景是碎片累积的主要来源，需重点关注。

1. 连接管理：短连接高频创建与释放（最常见场景）

MySQL 的 “连接内存” 是碎片重灾区 —— 每个客户端连接会占用独立的内存空间（用于存储会话变量、临时 SQL 缓存、连接状态等），默认情况下，一个连接的初始内存占用约 256KB（由sort_buffer_size、join_buffer_size等会话级参数决定）。

当业务采用 “短连接”（如 PHP 默认的短连接模式）时，会频繁触发 “连接创建 - 内存分配” 与 “连接关闭 - 内存释放” 循环：

• 分配时：内存分配器为新连接分配连续内存块（如 512KB）；

• 释放时：连接关闭后，该内存块被标记为空闲，但若后续新连接申请的内存尺寸与空闲块不匹配（如后续连接需 64KB，而空闲块是 512KB），则该 512KB 块会被拆分为 “64KB（分配）+ 448KB（空闲碎片）”；

• 累积效应：高频短连接持续操作，会产生大量 “小尺寸空闲碎片”（如 32KB、64KB），这些碎片无法被后续需要大内存的操作（如大查询的排序缓存）复用，最终导致内存持续增长。

示例：某电商 MySQL 服务器，峰值时每秒创建 1000 个短连接，运行 1 个月后，内存从 3GB 增长至 7GB，通过内存分析工具发现，约 40% 的内存是 “小于 128KB 的空闲碎片”。

2. 缓存组件：InnoDB Buffer Pool 的碎片（影响最深远）

InnoDB Buffer Pool（IBP）是 MySQL 最核心的内存组件（通常占 MySQL 总内存的 50%-80%），用于缓存表数据与索引。IBP 本身的 “页管理机制” 会产生碎片，且碎片会随数据操作持续累积：

• 页分配与淘汰：IBP 以 “16KB 页” 为单位缓存数据，当缓存页被淘汰（如 LRU 算法）时，会释放对应的 16KB 内存块；但若 IBP 中存在 “不连续的空闲页”（如中间某页被淘汰，前后页仍活跃），则这些空闲页会成为 “页级碎片”；

• 参数配置不当：若innodb_buffer_pool_size设置过小，会导致 IBP 频繁触发页淘汰，加速碎片产生；若开启innodb_buffer_pool_instances（多实例 IBP）但实例数量过多（如超过 CPU 核心数），会导致每个实例的空闲页无法跨实例复用，形成 “实例内碎片”；

• 大表批量操作：对大表执行DELETE（批量删除）或UPDATE（修改索引字段）时，会导致 IBP 中的大量缓存页失效并被淘汰，产生集中式碎片，短期内内存碎片率可从 5% 飙升至 20%。

3. 临时表与排序：会话级内存的频繁申请与释放

MySQL 执行复杂 SQL（如带GROUP BY、ORDER BY、DISTINCT的查询）时，会创建临时表（内存临时表或磁盘临时表），并申请sort_buffer_size（排序缓存）、join_buffer_size（连接缓存）等会话级内存。这些内存的 “短生命周期” 特性，极易产生碎片：

• 内存临时表：若临时表数据量未超过tmp_table_size（默认 16MB），会在内存中创建，查询结束后释放内存；但释放的内存块若尺寸不规则（如因临时表数据量波动导致分配的块大小不同），会成为碎片；

• 排序缓存复用率低：sort_buffer_size是 “按需分配”（若排序数据量小，实际分配的内存小于配置值），不同查询的排序需求差异大（如一次排序需 8KB，另一次需 32KB），导致释放的内存块难以复用；

• 磁盘临时表间接影响：若临时表溢出到磁盘（超过tmp_table_size），MySQL 会申请内存用于磁盘 I/O 缓存（如read_buffer_size），这些缓存的频繁分配与释放，也会加剧碎片累积。

4. 内存分配器特性：默认 glibc 的 “碎片化缺陷”

MySQL 默认使用操作系统的glibc内存分配器（Linux 系统），而glibc的malloc/free机制存在 “碎片化倾向”—— 尤其在 “小内存块高频分配 - 释放” 场景下，碎片率远高于专业分配器（如 tcmalloc、jemalloc）：

• glibc 的分配策略：glibc采用 “分区分配”（将内存按尺寸分为多个区间，如小块 < 1KB、中块 1KB-128KB、大块 > 128KB），小内存块的释放会优先回收到 “小 block 池”，但若后续申请的尺寸不在该区间，则无法复用，形成碎片；

• 缺乏碎片合并：glibc对空闲块的 “合并机制” 较弱，仅当相邻空闲块存在时才会合并为大块，若空闲块被活跃块分隔，则无法合并，导致小碎片长期累积；

• 对比差异：相同业务场景下，使用jemalloc的 MySQL 内存碎片率通常比glibc低 30%-50%，内存增长速度显著放缓。

5. 存储引擎与 SQL 操作：特定场景的碎片触发

除上述通用场景外，部分存储引擎特性与 SQL 操作会针对性产生碎片：

• MyISAM 存储引擎：MyISAM 的索引缓存（key_buffer_size）采用 “固定块大小”（如 1KB），若索引查询频繁且索引块大小不统一，会导致缓存块释放后形成碎片；

• 大结果集查询：执行SELECT * FROM 大表（无 LIMIT 限制）时，MySQL 会申请大量内存用于存储结果集，查询结束后释放的内存块若尺寸过大（如几 MB），后续小内存申请无法复用，成为 “大块碎片”；

• 事务日志缓存：InnoDB 的 redo log 缓存（innodb_log_buffer_size）虽会定期刷盘，但缓存块的动态调整（如峰值时临时扩容）也可能产生碎片，尤其当innodb_log_buffer_size设置过小时。

三、实战检测：3 步定位 MySQL 内存碎片问题

要解决内存碎片，需先通过 “系统层 - MySQL 层 - 分配器层” 三级检测，确认碎片是否存在、碎片率有多高、碎片来源是什么 —— 避免将 “正常内存占用” 误判为 “碎片问题”。

1. 第一步：系统层检测 —— 判断整体内存增长与碎片趋势

通过 Linux 系统工具，先宏观判断 MySQL 进程的内存占用是否异常，是否存在 “内存增长但空闲内存也增长” 的碎片特征：

（1）用top/htop观察内存占用

# 查看MySQL进程的内存占用（PID为MySQL的进程ID，可通过ps aux | grep mysql获取）

top -p 12345

• 关注%MEM（内存占比）与VSZ（虚拟内存大小）、RSS（物理内存大小）：若RSS持续增长，且无明显业务负载增加，可能存在碎片；

• 对比free -h的available（可用内存）：若RSS增长的同时，available内存也在增长（说明系统有空闲内存，但 MySQL 无法复用，可能是碎片导致），需进一步检测。

（2）用vmstat观察内存交换（排除 Swap 干扰）

vmstat 1 10  # 每秒输出1次，共10次

• 关注si（从 Swap 读入内存的大小）与so（写入 Swap 的大小）：若si/so持续大于 0，说明系统内存不足导致 Swap 交换，需先排除 “内存配置不足” 的问题（如 IBP 设置过大），再判断碎片。

2. 第二步：MySQL 层检测 —— 定位内部内存组件的碎片

通过 MySQL 自带工具，分析内部内存组件（如连接数、IBP、临时表）的使用情况，判断碎片来源：

（1）连接数与会话内存检测

-- 1. 查看当前连接数与历史峰值（判断是否短连接高频）

show status like 'Threads_connected';  -- 当前连接数

show status like 'Threads_created';   -- 累计创建连接数（若远大于当前连接数，说明短连接多）

show variables like 'max_connections'; -- 最大连接数

-- 2. 查看会话级内存参数配置（判断单连接内存是否过大）

show variables like '%buffer_size%';   -- 如sort_buffer_size、join_buffer_size

show variables like 'tmp_table_size';  -- 内存临时表阈值

• 若Threads_created/Threads_connected比值大于 10（如累计创建 10 万连接，当前仅 1 万），说明短连接高频，是碎片高发场景；

• 若会话级参数（如sort_buffer_size）设置过大（如超过 2MB），会增加单连接内存分配尺寸，加剧碎片。

（2）InnoDB Buffer Pool 碎片检测

-- 查看IBP的碎片率与使用情况

show engine innodb statusG

在输出结果的BUFFER POOL AND MEMORY段，关注以下指标：

• Free buffers：空闲页数量（单位：16KB 页）；

• Database pages：已使用的数据库页数量；

• Buffer pool size：总页数量；

• 碎片率计算：碎片率 = Free buffers / Buffer pool size * 100%（若碎片率超过 15%，且Free buffers绝对值大，说明 IBP 存在明显碎片）。

（3）临时表与排序操作检测

-- 查看内存临时表与磁盘临时表的数量（判断是否频繁创建临时表）

show status like 'Created_tmp_tables';    -- 累计内存临时表数量

show status like 'Created_tmp_disk_tables';-- 累计磁盘临时表数量

-- 查看排序操作次数（判断是否高频排序）

show status like 'Sort_rows';  -- 累计排序行数

show status like 'Sort_scan';  -- 全表扫描后的排序次数（效率低，易产生碎片）

• 若Created_tmp_tables/Created_tmp_disk_tables比值小于 10（如磁盘临时表占比超过 10%），说明大量临时表溢出到磁盘，会加剧内存碎片；

• 若Sort_scan数值较大（如超过 1 万），说明存在大量未使用索引的排序，会频繁申请sort_buffer，产生碎片。

3. 第三步：分配器层检测 —— 精准量化碎片率

通过第三方工具（如jemalloc的jeprof、tcmalloc的heap profiler），直接分析 MySQL 进程的内存分配情况，量化碎片率：

（1）使用jemalloc的jeprof分析（推荐）

若 MySQL 已配置jemalloc内存分配器（后续优化会讲），可通过jeprof生成内存剖面图：

# 1. 安装jemalloc（需提前编译时指定）

# 2. 生成MySQL进程的内存快照（PID为MySQL进程ID）

jeprof --pdf `which mysqld` 12345 > mysql_memory_profile.pdf

在生成的 PDF 报告中，关注：

• Fragmentation：整体碎片率（若超过 20%，需重点优化）；

• Free Blocks：空闲块的尺寸分布（若大量空闲块尺寸 < 256KB，且占比超过 30%，说明是短连接或临时表导致的碎片）；

• Allocated Blocks：已分配块的尺寸分布（对比空闲块尺寸，判断复用率）。

（2）使用glibc的malloc_info分析（默认分配器）

若使用默认glibc，可通过malloc_info查看内存分配细节：

# 向MySQL进程发送信号，生成malloc信息（PID为MySQL进程ID）

sudo kill -SIGUSR2 12345

# 查看日志（默认路径在/var/log/mysql/error.log）

grep -A 100 "MALLOC INFO" /var/log/mysql/error.log

日志中会输出 “空闲块链表”（free lists）的信息，若某一尺寸区间的空闲块数量多（如size 65536的空闲块有 1000 个），但该尺寸的分配请求少，说明是碎片。

四、解决方案：从临时缓解到长期优化的 4 层策略

针对 MySQL 内存碎片导致的内存持续增长，需分 “临时解决（快速释放碎片）”“中期优化（参数调整）”“长期根治（架构与分配器优化）” 三个层次处理，确保覆盖不同紧急程度的需求。

1. 临时缓解：快速释放已产生的碎片（治标）

当内存碎片已导致内存持续增长至警戒值（如超过系统内存的 80%），需先通过以下方法临时释放碎片，避免服务宕机：

（1）重启 MySQL（最直接但影响业务）

重启 MySQL 会彻底释放进程的所有内存（包括碎片），是最快的临时解决方案，但会中断业务，仅适用于非核心业务或维护窗口：

# 安全重启MySQL（避免数据丢失）

sudo systemctl stop mysql

sudo systemctl start mysql

注意：重启前需确保 InnoDB 事务已提交（show engine innodb statusG查看Pending writes是否为 0），避免崩溃恢复时间过长。

（2）优化 InnoDB Buffer Pool 碎片（无感知）

若碎片主要来自 IBP，可通过 “调整 IBP 大小” 触发碎片整理（MySQL 5.7 + 支持动态调整innodb_buffer_pool_size）：

-- 1. 查看当前IBP大小

show variables like 'innodb_buffer_pool_size';  -- 假设当前为4GB

-- 2. 临时减小IBP（释放空闲碎片），需设置为小于当前值（如3.8GB）

set global innodb_buffer_pool_size = 4026531840;  -- 3.8GB = 3.8 * 1024^3

-- 3. 恢复IBP原大小（重新分配连续内存）

set global innodb_buffer_pool_size = 4294967296;  -- 4GB

原理：减小 IBP 时，MySQL 会优先释放空闲碎片对应的内存；恢复大小时，会申请连续的物理内存，减少碎片率。该操作无业务中断，碎片率可降低 10%-15%。

（3）清理临时表与会话缓存

若碎片来自临时表或会话内存，可通过 “杀死空闲连接”“清理临时表” 释放部分碎片：

-- 1. 杀死空闲超过30分钟的连接（需先开启performance_schema）

select concat('kill ', id, ';') 

from performance_schema.threads 

where type = 'FOREGROUND' 

  and TIME_TO_SEC(timediff(now(), last_seen)) > 1800;  -- 空闲30分钟

-- 2. 手动清理内存临时表（仅清理当前会话的临时表）

drop temporary table if exists tmp_table;  -- 若知道临时表名

注意：杀死连接前需确认连接无活跃事务（show processlist查看State是否为Sleep），避免事务回滚。

2. 中期优化：调整 MySQL 参数减少碎片产生（治本）

通过优化 MySQL 核心参数，从源头降低碎片产生的频率，适用于多数场景：

（1）优化连接管理：减少短连接高频创建

• 启用连接池：业务层使用连接池（如 Java 的 HikariCP、PHP 的 pdo-mysql-pool），将短连接转为长连接，减少 “连接创建 - 释放” 循环，碎片产生量可降低 50% 以上；

• 调整连接超时参数：延长空闲连接超时时间，避免频繁断开：

show variables like 'wait_timeout';     -- 非交互式连接超时（默认8小时）

show variables like 'interactive_timeout';-- 交互式连接超时（默认8小时）

-- 若短连接多，可适当延长至24小时（需结合连接池使用，避免连接数超限）

set global wait_timeout = 86400;

set global interactive_timeout = 86400;

• 限制单连接内存：减小会话级内存参数（如sort_buffer_size、join_buffer_size）的默认值，避免单连接内存分配过大导致碎片：

-- 调整为合理值（根据业务查询复杂度，一般sort_buffer_size设为64KB-256KB）

set global sort_buffer_size = 65536;    -- 64KB

set global join_buffer_size = 65536;    -- 64KB

set global tmp_table_size = 16777216;  -- 16MB（避免内存临时表过大）

（2）优化 InnoDB Buffer Pool：降低页级碎片

• 合理设置 IBP 大小与实例数：

-- 1. IBP大小建议设为系统内存的50%-70%（避免系统内存不足）

set global innodb_buffer_pool_size = 8589934592;  -- 8GB（假设系统内存16GB）

-- 2. 实例数（innodb_buffer_pool_instances）设为CPU核心数的1-2倍（如8核CPU设为8）

set global innodb_buffer_pool_instances = 8;

• 开启 IBP 碎片自动整理：MySQL 8.0.23 + 支持innodb_buffer_pool_autoincr_ratio，自动调整空闲页合并策略：

set global innodb_buffer_pool_autoincr_ratio = 50;  -- 50%的空闲页用于合并

• 避免大表批量删除 / 更新：对大表操作时，采用 “分批处理”（如每次删除 1000 行），减少 IBP 缓存页集中淘汰，降低碎片产生：

-- 分批删除大表数据（避免一次性删除10万行）

while exists (select 1 from big_table where create_time < '2024-01-01') do

   delete from big_table where create_time < '2024-01-01' limit 1000;

   commit;

   sleep(1);  -- 避免锁表

end while;

（3）优化临时表与排序：减少会话内存碎片

• 强制使用索引排序：优化 SQL，避免Sort_scan（全表扫描排序），减少sort_buffer的频繁申请：

-- 原SQL（无索引，触发Sort_scan）

select * from orders order by create_time;

-- 优化后（创建索引，触发Sort_index）

create index idx_orders_create_time on orders(create_time);

select * from orders order by create_time;  -- 利用索引排序，无需申请sort_buffer

• 限制磁盘临时表数量：提高tmp_table_size与max_heap_table_size（两者需一致），减少临时表溢出到磁盘：

set global tmp_table_size = 33554432;     -- 32MB

set global max_heap_table_size = 33554432;-- 32MB

3. 长期根治：更换内存分配器与架构优化（彻底解决）

若上述优化后碎片问题仍频繁出现，需从 “内存分配器” 与 “MySQL 架构” 入手，彻底根治碎片隐患：

（1）更换为低碎片内存分配器（核心优化）

将 MySQL 的默认glibc分配器更换为jemalloc或tcmalloc，这两种分配器针对 “高频小内存分配” 做了优化，碎片率可降低 30%-60%：

方案 1：使用 jemalloc（推荐，兼容性好）

# 1. 安装jemalloc（CentOS示例）

sudo yum install epel-release

sudo yum install jemalloc-devel

# 2. 重新编译MySQL，指定jemalloc（或动态加载）

# 编译时指定：

cmake . -DWITH_JEMALLOC=ON

# 或动态加载（无需重新编译，临时生效）：

sudo echo "LD_PRELOAD=/usr/lib64/libjemalloc.so.1" >> /etc/profile

source /etc/profile

sudo systemctl restart mysql

# 3. 验证是否加载成功

sudo lsof -n -p 12345 | grep jemalloc  # 12345为MySQL PID，有输出则成功

方案 2：使用 tcmalloc（适合高并发场景）

# 1. 安装tcmalloc（CentOS示例）

sudo yum install gperftools-devel

# 2. 动态加载

sudo echo "LD_PRELOAD=/usr/lib64/libtcmalloc.so" >> /etc/profile

source /etc/profile

sudo systemctl restart mysql

# 3. 验证

sudo lsof -n -p 12345 | grep tcmalloc

（2）架构优化：减少单机 MySQL 的内存压力

• 读写分离：将读请求分流到从库，减少主库的连接数与临时表操作，降低碎片产生；

• 分库分表：对大表（如超过 1000 万行）进行分库分表（如按时间、按用户 ID 哈希），减少单表查询时的临时表与排序操作，间接减少碎片；

• 使用 MySQL 8.0 + 版本：新版本对内存分配机制做了优化（如 IBP 碎片自动整理、临时表内存管理优化），碎片率比 5.7 版本低 15%-20%。

4. 定期维护：建立碎片监测与优化的长效机制

内存碎片是 “累积性问题”，需定期监测与维护，避免再次爆发：

• 每日监测：用脚本定期采集Threads_created、IBP碎片率、内存使用趋势，当碎片率超过 20% 或内存增长超过 10%/ 周时，触发告警；

• 每周优化：执行OPTIMIZE TABLE（针对 MyISAM 表）或ALTER TABLE ... FORCE（针对 InnoDB 表），整理表碎片（间接减少内存碎片）；

• 每月复盘：分析内存碎片来源（如短连接、临时表、IBP），针对性调整参数（如增加连接池大小、优化 SQL）。

五、实战案例：某电商 MySQL 内存持续增长的解决过程

场景描述

某电商 MySQL 服务器（8 核 16GB，MySQL 5.7，默认 glibc 分配器），运行 3 个月后，内存从 4GB 增长至 12GB，top显示RSS=12GB，free -h显示available=3GB（存在大量空闲内存但无法复用），业务为 PHP 短连接（Threads_created=50 万，Threads_connected=5000）。

解决步骤

1. 检测定位：

• 系统层：jeprof分析显示碎片率 28%，空闲块中 60% 是 < 128KB 的小碎片；

• MySQL 层：Threads_created/Threads_connected=100，短连接高频；IBP 碎片率 18%，Created_tmp_disk_tables占比 15%。

1. 临时缓解：

• 动态调整 IBP：从 8GB 减小至 7.5GB 再恢复，碎片率降至 10%；

• 杀死空闲 30 分钟以上的连接，释放 2GB 内存。

1. 中期优化：

• 业务层启用 PHP 连接池，Threads_created下降至 5 万 / 月；

• 调整参数：sort_buffer_size=64KB，tmp_table_size=32MB，innodb_buffer_pool_instances=8。

1. 长期根治：

• 更换为 jemalloc 分配器，碎片率稳定在 8% 以下；

• 升级 MySQL 至 8.0.32，启用 IBP 自动碎片整理。

1. 效果验证：

• 运行 2 个月后，内存稳定在 5GB-6GB，无持续增长；

• 碎片率长期低于 10%，无需再频繁重启 MySQL。

六、总结：内存碎片是 “累积性隐患”，需长期监测与优化

MySQL 内存碎片导致的内存持续增长，并非 “不可解” 的难题，而是 “需长期关注” 的累积性隐患。其核心解决逻辑是：

• 先定位：通过系统工具、MySQL 自带命令、分配器分析工具，明确碎片来源（短连接、IBP、临时表）；

• 再解决：临时缓解用 “重启 / IBP 调整”，中期优化用 “参数调整”，长期根治用 “分配器更换 + 架构优化”；

• 后维护：建立定期监测与优化机制，避免碎片再次累积。

对 MySQL 运维而言，内存碎片的管理不仅是 “解决当前问题”，更是 “预防未来风险”—— 只有结合业务场景（如短连接 / 长连接）、MySQL 特性（如 IBP、临时表）、分配器优化，才能彻底摆脱 “内存持续增长” 的困扰，保障 MySQL 服务器的稳定与高效。

推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !

免费加入阅读：https://edu.cda.cn/goods/show/3151?targetId=5147&preview=0