大家好我是老张。连着写了三天博客安全系列今天换个话题——生产踩坑。上周写个人博客后台写嗨了差点在生产环境捅个大篓子。⚠️声明本文基于真实生产环境排查案例编写已对 IP 地址、实例名、库名/表名、密码等敏感信息做脱敏处理命令可直接复制执行。磁盘 80% 告警碎片 52GTRUNCATE 一下不就完了我相信绝大多数运维人的第一反应都是这个。说实话我当时也这么想的。直到我多做了一个操作——查了一下数据的最晚写入时间。然后冷汗都下来了。 告警来了某天下午监控弹出一条告警Meta MySQL 磁盘使用率超过 80%。进云平台控制台一看实例规格 4C16G磁盘 150GB 本地 SSD用了 120G。主节点 80.07%备节点 79.72%同步正常。先看磁盘分拆数据 119.6G Binlog 509M 日志 5M。Binlog 才 500M——不是 Binlog 堆积数据文件有问题。 排查差额到底在哪SSH 到管理节点进 Pod 直连 MySQL# SSH 到管理节点 ssh 管理节点IP # 进 Pod 直连 MySQL kubectl exec -it pod名 -n namespace -- mysql -uroot -p先 SQL 统计各库大小SELECT table_schema AS 库名, ROUND(SUM(data_length index_length) / 1024/1024/1024, 2) AS SQL统计(GB) FROM information_schema.tables WHERE table_schema NOT IN (mysql,information_schema,performance_schema,sys) GROUP BY table_schema ORDER BY 2 DESC;库SQL 统计库A16.8G库B8.3G库C5.1G库D5.1G所有库加起来才 ~44G。但磁盘用了 120G——差了 76G。再用磁盘实际占用对比 SQL 统计定位差额# 进 Pod 的 mysql 容器直接 du 各库目录 kubectl exec -it pod名 -n namespace -c mysql -- bash -c \ du -sh /var/lib/mysql/*/ 2/dev/null | sort -rh | head -10库目录磁盘实际SQL 统计碎片库B60G8.3G51.7G库A23G16.8G6.2G库C7.6G5.1G2.5G库D6.8G5.1G1.7G一个库吃掉了 52G 碎片。精确量化data_free 排名要找碎片最大的表最快的方式是看各表的.ibd文件实际大小再跟 SQL 统计对比# 进 Pod查目标库下所有 .ibd 文件大小 kubectl exec -it pod名 -n namespace -c mysql -- bash -c \ du -sh /var/lib/mysql/库名/*.ibd 2/dev/null | sort -rh | head -15结果跟 du 数据吻合——8 张表的.ibd文件远大于 SQL 统计值。下一步用data_free精确量化。DBA 要求用information_schema.TABLES的data_free字段——这个字段统计的是 InnoDB 内部已分配但未使用的空间比du更准确SELECT CONCAT(table_schema, ., table_name) table_name, ROUND((data_length index_length) / 1024/1024, 2) AS 数据大小(M), ROUND(data_free / 1024/1024, 2) AS 碎片(M), (100*(data_free/(data_lengthindex_lengthdata_free))) AS 浪费比例% FROM information_schema.TABLES WHERE table_schema NOT IN (mysql,information_schema,performance_schema,sys) ORDER BY data_free DESC LIMIT 8;结果触目惊心表实际数据碎片总占用浪费比例表11.4G9.2G10.6G86.3%表2666M7.6G8.3G92.0%表3152M6.6G6.8G97.8%表41.1G5.2G6.4G81.7%表5103M4.3G4.4G97.7%表669M4.0G4.1G98.3%表783M3.2G3.3G97.5%表82.6G1.9G4.6G41.0%8 张表合计碎片约 46G大部分浪费比例 80%。其中表 3 最夸张——实际数据只有 152M碎片却有 6.6G浪费 97.8%。看到这个数据我脑子里的第一反应不是这表还在用吗——而是这表居然能有这么多碎片98% 的浪费率大脑会直接下结论这是张废弃表没人管了。更何况业务方上周刚跟我说过库B那几张历史表没用了有空清一下。到这一步直觉告诉我TRUNCATE 掉就完事了。⚠️ 转折多做了一个操作正准备提单 TRUNCATE突然想到一个问题——这表还在用吗先看表结构找时间字段SHOW FULL COLUMNS FROM 库B.表1;常见时间字段叫created_time、gmt_create、create_time找到后查数据时间范围SELECT MIN(created_time) AS 最早创建, MAX(created_time) AS 最晚创建, COUNT(*) AS 总行数 FROM 库B.表1;结果最早创建: 2026-07-25 23:15:02 最晚创建: 2026-08-04 11:00:31 ← 就是现在 总行数: 202,257最晚创建时间就是查询时刻——这张表是活的实时高频率写入中。20 万行记录仅 10 天数据9.2G 碎片来自频繁 INSERT/UPDATE/DELETEInnoDB 来不及回收。如果刚才直接 TRUNCATE几 万行业务数据就没了。 冷汗都下来了。 决策矩阵面对碎片表判断能不能 TRUNCATE 的关键不是碎片大小而是数据时间范围时间特征判断方案最早 6 个月前最晚也是 6 个月前冷数据TRUNCATE确认业务已停最早 1 个月前最晚 此刻活跃写入OPTIMIZE不能 TRUNCATE时间跨度短 行数多高频写入碎片低峰期 OPTIMIZE️ OPTIMIZE 执行比预估快 20 倍方案确定逐表OPTIMIZE TABLE变更窗口定在下午 6 点。-- 逐表执行每张跑完再跑下一张 OPTIMIZE TABLE 库B.表1; OPTIMIZE TABLE 库B.表2; OPTIMIZE TABLE 库B.表3; OPTIMIZE TABLE 库B.表4; OPTIMIZE TABLE 库B.表5; OPTIMIZE TABLE 库B.表6; OPTIMIZE TABLE 库B.表7; OPTIMIZE TABLE 库B.表8;预估表 1 有 10.6G 总占用按经验得跑十几分钟。8 张表下来至少 1 小时。实际执行#表碎片实际耗时结果1表81.9G1m39s✅2表73.2G0.6s✅3表64.0G2.9s✅4表54.3G3.4s✅5表45.2G6.4s✅6表36.6G5.3s✅7表27.6G15.6s✅8表19.2G9.7s✅合计~46G~3 分钟8 张表跑完总共不到 3 分钟。为什么这么快因为表虽然总占用 8-10G但 86-98% 是碎片。OPTIMIZE 只拷贝有效数据——10G 的表实际数据只有 1.4G搬这点东西当然快。 最终效果磁盘使用率80% → 53%回收约 40G。节点磁盘数据Binlog同步主52.93%78.8G583M0ms备52.92%78.7G560M1s❓ 读者可能会问碎片这么大了为什么不清很简单之前没人知道。业务方表还在正常写入不知道有碎片问题开发只管用业务逻辑不会定期查data_freeDBA管几百个实例顾不上这种还没爆雷的碎片运维只看磁盘使用率80% 告警才拉群这就是运维的日常——问题不到炸出来的那一刻没人会主动关注。如果今天不是我多查了一步MAX(created_time)这张表就没了。 老张的经验总结✅ 做对了什么先排除 Binlog——控制台分拆一看 500M直接跳过不必要的排查du vs SQL 双对比——磁盘 60G、SQL 8G差额就是碎片定位精准data_free 精确量化——比 du 估算更准而且是 DBA 认可的标准指标数据活跃度验证——这是整个排查中最关键的一步。碎片再大也不能无脑 TRUNCATEOPTIMIZE 比预估快——碎片率越高跑得越快因为只搬有效数据⚠️ 如果再遇到这种事先查时间范围再做决策——不管你多确定这表没用了不管业务方跟你说过多少次这表可以清跑一条SELECT MIN/MAX只要 0.1 秒。别人说的没用跟数据库里的真没用中间隔了 几万行数据。定时统计 data_free——可以加到巡检脚本里碎片率 50% 就告警别等 80% 了再处理碎片率越高的表OPTIMIZE 越快——这个反直觉的事实记下来业务方说没用不算数最后一条写入是半年前才算数——口头承诺不可信数据库里的时间戳才是铁证 碎片排查命令速查-- 1. 查看各库碎片 Top SELECT table_schema AS 库, ROUND(SUM(data_free) / 1024/1024/1024, 2) AS 碎片(GB) FROM information_schema.TABLES WHERE table_schema NOT IN (mysql,information_schema,performance_schema,sys) GROUP BY table_schema ORDER BY 2 DESC; -- 2. 查看某库表碎片排名含浪费比例 SELECT table_name AS 表名, ROUND((data_length index_length) / 1024/1024, 2) AS 数据(M), ROUND(data_free / 1024/1024, 2) AS 碎片(M), ROUND(100 * data_free / (data_length index_length data_free), 1) AS 浪费% FROM information_schema.TABLES WHERE table_schema 你的库名 ORDER BY data_free DESC LIMIT 10; -- 3. ⚠️ 关键查数据时间范围决定能不能 TRUNCATE SELECT MIN(created_time), MAX(created_time), COUNT(*) FROM 你的库.你的表; -- 4. OPTIMIZE低峰期执行 OPTIMIZE TABLE 你的库.你的表; 适合谁看场景推荐程度MySQL 磁盘告警不知道怎么排查⭐⭐⭐⭐⭐遇到过碎片但不确定 TRUNCATE 还是 OPTIMIZE⭐⭐⭐⭐⭐想知道 data_free 怎么用⭐⭐⭐⭐纯开发不碰数据库运维⭐⭐ 聊聊你的经历你遇到过 MySQL 碎片占磁盘一半以上的情况吗TRUNCATE 和 OPTIMIZE 之间你一般怎么选有没有踩过坑你们会在巡检里加 data_free 监控吗原文链接 个人博客欢迎关注交流 山外云的Vlog MySQL 磁盘 80% 告警，碎片 52G，我差点 TRUNCATE 掉正在写入的业务表
大家好我是老张。连着写了三天博客安全系列今天换个话题——生产踩坑。上周写个人博客后台写嗨了差点在生产环境捅个大篓子。⚠️声明本文基于真实生产环境排查案例编写已对 IP 地址、实例名、库名/表名、密码等敏感信息做脱敏处理命令可直接复制执行。磁盘 80% 告警碎片 52GTRUNCATE 一下不就完了我相信绝大多数运维人的第一反应都是这个。说实话我当时也这么想的。直到我多做了一个操作——查了一下数据的最晚写入时间。然后冷汗都下来了。 告警来了某天下午监控弹出一条告警Meta MySQL 磁盘使用率超过 80%。进云平台控制台一看实例规格 4C16G磁盘 150GB 本地 SSD用了 120G。主节点 80.07%备节点 79.72%同步正常。先看磁盘分拆数据 119.6G Binlog 509M 日志 5M。Binlog 才 500M——不是 Binlog 堆积数据文件有问题。 排查差额到底在哪SSH 到管理节点进 Pod 直连 MySQL# SSH 到管理节点 ssh 管理节点IP # 进 Pod 直连 MySQL kubectl exec -it pod名 -n namespace -- mysql -uroot -p先 SQL 统计各库大小SELECT table_schema AS 库名, ROUND(SUM(data_length index_length) / 1024/1024/1024, 2) AS SQL统计(GB) FROM information_schema.tables WHERE table_schema NOT IN (mysql,information_schema,performance_schema,sys) GROUP BY table_schema ORDER BY 2 DESC;库SQL 统计库A16.8G库B8.3G库C5.1G库D5.1G所有库加起来才 ~44G。但磁盘用了 120G——差了 76G。再用磁盘实际占用对比 SQL 统计定位差额# 进 Pod 的 mysql 容器直接 du 各库目录 kubectl exec -it pod名 -n namespace -c mysql -- bash -c \ du -sh /var/lib/mysql/*/ 2/dev/null | sort -rh | head -10库目录磁盘实际SQL 统计碎片库B60G8.3G51.7G库A23G16.8G6.2G库C7.6G5.1G2.5G库D6.8G5.1G1.7G一个库吃掉了 52G 碎片。精确量化data_free 排名要找碎片最大的表最快的方式是看各表的.ibd文件实际大小再跟 SQL 统计对比# 进 Pod查目标库下所有 .ibd 文件大小 kubectl exec -it pod名 -n namespace -c mysql -- bash -c \ du -sh /var/lib/mysql/库名/*.ibd 2/dev/null | sort -rh | head -15结果跟 du 数据吻合——8 张表的.ibd文件远大于 SQL 统计值。下一步用data_free精确量化。DBA 要求用information_schema.TABLES的data_free字段——这个字段统计的是 InnoDB 内部已分配但未使用的空间比du更准确SELECT CONCAT(table_schema, ., table_name) table_name, ROUND((data_length index_length) / 1024/1024, 2) AS 数据大小(M), ROUND(data_free / 1024/1024, 2) AS 碎片(M), (100*(data_free/(data_lengthindex_lengthdata_free))) AS 浪费比例% FROM information_schema.TABLES WHERE table_schema NOT IN (mysql,information_schema,performance_schema,sys) ORDER BY data_free DESC LIMIT 8;结果触目惊心表实际数据碎片总占用浪费比例表11.4G9.2G10.6G86.3%表2666M7.6G8.3G92.0%表3152M6.6G6.8G97.8%表41.1G5.2G6.4G81.7%表5103M4.3G4.4G97.7%表669M4.0G4.1G98.3%表783M3.2G3.3G97.5%表82.6G1.9G4.6G41.0%8 张表合计碎片约 46G大部分浪费比例 80%。其中表 3 最夸张——实际数据只有 152M碎片却有 6.6G浪费 97.8%。看到这个数据我脑子里的第一反应不是这表还在用吗——而是这表居然能有这么多碎片98% 的浪费率大脑会直接下结论这是张废弃表没人管了。更何况业务方上周刚跟我说过库B那几张历史表没用了有空清一下。到这一步直觉告诉我TRUNCATE 掉就完事了。⚠️ 转折多做了一个操作正准备提单 TRUNCATE突然想到一个问题——这表还在用吗先看表结构找时间字段SHOW FULL COLUMNS FROM 库B.表1;常见时间字段叫created_time、gmt_create、create_time找到后查数据时间范围SELECT MIN(created_time) AS 最早创建, MAX(created_time) AS 最晚创建, COUNT(*) AS 总行数 FROM 库B.表1;结果最早创建: 2026-07-25 23:15:02 最晚创建: 2026-08-04 11:00:31 ← 就是现在 总行数: 202,257最晚创建时间就是查询时刻——这张表是活的实时高频率写入中。20 万行记录仅 10 天数据9.2G 碎片来自频繁 INSERT/UPDATE/DELETEInnoDB 来不及回收。如果刚才直接 TRUNCATE几 万行业务数据就没了。 冷汗都下来了。 决策矩阵面对碎片表判断能不能 TRUNCATE 的关键不是碎片大小而是数据时间范围时间特征判断方案最早 6 个月前最晚也是 6 个月前冷数据TRUNCATE确认业务已停最早 1 个月前最晚 此刻活跃写入OPTIMIZE不能 TRUNCATE时间跨度短 行数多高频写入碎片低峰期 OPTIMIZE️ OPTIMIZE 执行比预估快 20 倍方案确定逐表OPTIMIZE TABLE变更窗口定在下午 6 点。-- 逐表执行每张跑完再跑下一张 OPTIMIZE TABLE 库B.表1; OPTIMIZE TABLE 库B.表2; OPTIMIZE TABLE 库B.表3; OPTIMIZE TABLE 库B.表4; OPTIMIZE TABLE 库B.表5; OPTIMIZE TABLE 库B.表6; OPTIMIZE TABLE 库B.表7; OPTIMIZE TABLE 库B.表8;预估表 1 有 10.6G 总占用按经验得跑十几分钟。8 张表下来至少 1 小时。实际执行#表碎片实际耗时结果1表81.9G1m39s✅2表73.2G0.6s✅3表64.0G2.9s✅4表54.3G3.4s✅5表45.2G6.4s✅6表36.6G5.3s✅7表27.6G15.6s✅8表19.2G9.7s✅合计~46G~3 分钟8 张表跑完总共不到 3 分钟。为什么这么快因为表虽然总占用 8-10G但 86-98% 是碎片。OPTIMIZE 只拷贝有效数据——10G 的表实际数据只有 1.4G搬这点东西当然快。 最终效果磁盘使用率80% → 53%回收约 40G。节点磁盘数据Binlog同步主52.93%78.8G583M0ms备52.92%78.7G560M1s❓ 读者可能会问碎片这么大了为什么不清很简单之前没人知道。业务方表还在正常写入不知道有碎片问题开发只管用业务逻辑不会定期查data_freeDBA管几百个实例顾不上这种还没爆雷的碎片运维只看磁盘使用率80% 告警才拉群这就是运维的日常——问题不到炸出来的那一刻没人会主动关注。如果今天不是我多查了一步MAX(created_time)这张表就没了。 老张的经验总结✅ 做对了什么先排除 Binlog——控制台分拆一看 500M直接跳过不必要的排查du vs SQL 双对比——磁盘 60G、SQL 8G差额就是碎片定位精准data_free 精确量化——比 du 估算更准而且是 DBA 认可的标准指标数据活跃度验证——这是整个排查中最关键的一步。碎片再大也不能无脑 TRUNCATEOPTIMIZE 比预估快——碎片率越高跑得越快因为只搬有效数据⚠️ 如果再遇到这种事先查时间范围再做决策——不管你多确定这表没用了不管业务方跟你说过多少次这表可以清跑一条SELECT MIN/MAX只要 0.1 秒。别人说的没用跟数据库里的真没用中间隔了 几万行数据。定时统计 data_free——可以加到巡检脚本里碎片率 50% 就告警别等 80% 了再处理碎片率越高的表OPTIMIZE 越快——这个反直觉的事实记下来业务方说没用不算数最后一条写入是半年前才算数——口头承诺不可信数据库里的时间戳才是铁证 碎片排查命令速查-- 1. 查看各库碎片 Top SELECT table_schema AS 库, ROUND(SUM(data_free) / 1024/1024/1024, 2) AS 碎片(GB) FROM information_schema.TABLES WHERE table_schema NOT IN (mysql,information_schema,performance_schema,sys) GROUP BY table_schema ORDER BY 2 DESC; -- 2. 查看某库表碎片排名含浪费比例 SELECT table_name AS 表名, ROUND((data_length index_length) / 1024/1024, 2) AS 数据(M), ROUND(data_free / 1024/1024, 2) AS 碎片(M), ROUND(100 * data_free / (data_length index_length data_free), 1) AS 浪费% FROM information_schema.TABLES WHERE table_schema 你的库名 ORDER BY data_free DESC LIMIT 10; -- 3. ⚠️ 关键查数据时间范围决定能不能 TRUNCATE SELECT MIN(created_time), MAX(created_time), COUNT(*) FROM 你的库.你的表; -- 4. OPTIMIZE低峰期执行 OPTIMIZE TABLE 你的库.你的表; 适合谁看场景推荐程度MySQL 磁盘告警不知道怎么排查⭐⭐⭐⭐⭐遇到过碎片但不确定 TRUNCATE 还是 OPTIMIZE⭐⭐⭐⭐⭐想知道 data_free 怎么用⭐⭐⭐⭐纯开发不碰数据库运维⭐⭐ 聊聊你的经历你遇到过 MySQL 碎片占磁盘一半以上的情况吗TRUNCATE 和 OPTIMIZE 之间你一般怎么选有没有踩过坑你们会在巡检里加 data_free 监控吗原文链接 个人博客欢迎关注交流 山外云的Vlog