Zabbix history表膨胀占满磁盘？从紧急清理到分区表与TimescaleDB治理

运维搞到一定时间，十有八九会遇到这么个场景：Zabbix监控系统跑了大半年，某天突然收到磁盘空间告警，登上服务器一看，MySQL里zabbix库占了几个T，其中history开头的几张表一张比一张肥。群里的同行几乎每周都有人问同样的问题——zabbix的history表怎么就这么能吃空间？这到底怎么解决？

这篇文章我把这个问题完整拆一遍。从磁盘爆满时的紧急止血，到分区表和TimescaleDB的长期治理，再到采集策略的架构级优化，最后附上我踩过坑之后的排查速查表。不管你是刚接手Zabbix的新人，还是被history表折腾过几次的老手，照着做基本都能把空间问题压下来。

1. 先搞清楚history和trends到底存了什么

1.1 Zabbix监控数据的存储逻辑

很多人一打开zabbix库，看到一堆history_xxx、trends_xxx表就发懵。其实Zabbix的监控数据存储逻辑很简单，分两条线：

• history系列表：保存每一个监控项每次采集到的原始值。比如CPU使用率每30秒采一次，那每次采集结果都会往history_uint这类表里写一条记录。这是最原始、最庞大的数据集合。
• trends系列表：系统每小时把原始值聚合成一条记录，存最大值、最小值、平均值。所有监控项在历史周期里都会做这个聚合，用于绘制长期趋势图。

这个地方有一个关键认知：history是原始数据，量大、增长快；trends是聚合数据，单条记录小、增长慢。当你发现数据库空间告急，先去看history_uint表的大小，十有八九就是它把磁盘撑爆的。

注意：Zabbix 4.0以后，trends表默认保留365天，history表默认保留29天。但如果你当初部署时随手把保留天数调大了，比如history设成90天甚至365天，那history表膨胀的速度会非常吓人。

1.2 history相关的几张表分别是谁

Zabbix不是把所有历史数据塞进一张表，而是按监控项的数据类型拆成了好几张，这一点在定位问题的时候非常重要：

我的经验是：绝大多数Zabbix环境里，业务监控项以整数型为主，所以history_uint和trends_uint占据了绝大部分存储。如果哪天你的监控项里加了文本巡检输出、日志采集，那history_str和history_log也可能突然膨胀。定位的时候不要只看一张表，要把整个history前缀的表全部列出来对比。

1.3 空间膨胀的三大根源

结合实际排查经验，history表变成磁盘杀手，逃不出下面三个原因：

1. 采集频率过高。这是个很容易被忽视的问题。一个监控项30秒采集一次，一天写入2880条记录；改成5秒采集一次，一天就是17280条，数据量直接翻6倍。很多人图监控数据“丝滑”就把采集间隔调得很小，完全没有计算过存储成本。
2. 保留周期过长。前端默认的History storage period是29天，但很多团队为了事后追溯，会改成90天甚至半年。保留周期每翻一倍，表体积就翻一倍，这是倍数关系，不是线性关系。
3. 监控项数量爆炸式增长。Zabbix的监控项数量会随着接入主机、模板自动发现不断膨胀。一台主机几十个监控项，几百台主机就是上万个监控项。尤其是用了低级别自动发现（LLD），实际监控项数量可能比你想象的多得多。

这三大根源往往会叠加。频率高、保留久、数量多，三管齐下，数据库增长速度和吃磁盘的速度都会让你措手不及。

2. 动手清理前，先把家底摸清楚

2.1 快速定位哪些表占用了大量空间

不管你想怎么处理，第一步永远是搞清楚现状。我在接手任何一台出问题的Zabbix服务器时，第一件事就是执行下面的SQL，把zabbix库里所有表的大小按照倒序排列：

SELECT table_name AS '表名', ROUND(((data_length + index_length) / 1024 / 1024), 2) AS '大小(MB)', table_rows AS '行数' FROM information_schema.tables WHERE table_schema = 'zabbix' ORDER BY (data_length + index_length) DESC LIMIT 20;

这条SQL会给你一张清晰的“空间占用排行榜”。正常情况下，排在前面的就是history_uint、history、trends_uint、trends这四张表。如果你发现history_log或者history_str排到了前面，那说明你的监控项里有一些日志采集、文本类监控项产生了大量数据，这种情况处理思路要稍作调整，但大方向一致。

另外别忽略索引空间。在MySQL里，InnoDB表的data_length是数据文件大小，index_length是索引文件大小。history表通常有itemid和clock两个核心索引，数据量一大，索引体积也很可观。所以清理数据之后，索引也会跟着缩水，但这可能需要重建表才能完全释放，具体我在后面说。

2.2 计算数据增长速度，决定保留周期

光知道当前表多大还不够，你还需要评估它每天增长多少，这样才能倒推出合理的保留周期。举个例子：

-- 查看history_uint最近7天写入多少条记录 SELECT FROM_UNIXTIME(clock, '%Y-%m-%d') AS 日期, COUNT(*) AS 记录数 FROM history_uint WHERE clock >= UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 7 DAY)) GROUP BY FROM_UNIXTIME(clock, '%Y-%m-%d') ORDER BY 日期 DESC;

假设结果中某一天写入1亿条记录，每条记录大概几十字节，那一天的新增空间就在5GB到10GB左右。这时你要算一笔账：磁盘剩余100GB，按每天5GB增长，最多只能撑20天。再结合你实际需要回查多少天的历史数据，就能定出保留周期。

我遇到过一个典型case：某客户保留周期设为90天，每天增长约8GB，单是history相关表就占掉700多GB。后来把保留周期压到14天，同时加了分区表管理，半年后整库占用稳定在200GB以内。这个数字变化会直观得多。

3. 从“紧急止血”到“长期治理”的完整解决思路

3.1 场景模型：不同阶段该用哪种方案

处理history数据占用问题，没有一招鲜吃遍天的办法。我个人把方案分成三层，根据紧急程度和实际情况组合使用：

大部分情况下，一套组合拳下来才能解决问题：先紧急删除一批老数据保住磁盘空间，然后调整保留周期和housekeeper配置，最后实施分区表或迁移TimescaleDB，让后续的数据清理变成自动化的“删分区”而不是痛苦的“DELETE大量数据”。

3.2 紧急止血：直接清理过期数据

当你磁盘已经告急，没有时间优雅地做长期方案，那么直接用DELETE语句清理指定日期之前的数据是最立竿见影的。下面以清理7天前的history_uint数据为例：

-- 先确认要删除的数据量级，心理有个数 SELECT COUNT(*) FROM history_uint WHERE clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 7 DAY)); -- 正式删除（注意：数据量大时会锁表，尽量在低峰期执行） DELETE FROM history_uint WHERE clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 7 DAY));

但这里有一个巨大的坑：如果你在history_uint表还有几个亿行数据的时候直接执行DELETE，轻则锁表导致Zabbix写入阻塞，重则把主库拖死。MySQL处理大事务时，锁定大量行、写undo log，整个库的性能都会受到严重影响。我见过有同行直接把数据库DELETE到卡死，最后只能重启MySQL的。

所以“紧急止血”也要讲策略：

• 先停掉Zabbix Server，或者至少停掉数据采集写入，避免边删边写。
• 用LIMIT分批删除，每批删除几百万条，循环多次，避免一个超大事务压垮数据库。
• 删除完成后执行OPTIMIZE TABLE重建表和索引，让磁盘空间真正释放出来。

分批删除的示意SQL可以这么写：

-- 循环执行下面这条，直到影响行数为0 DELETE FROM history_uint WHERE clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 7 DAY)) LIMIT 500000;

这条语句会一批一批地删除老数据，每批5万条，对数据库压力小很多。配合sleep间隔执行，比如每执行一批休息1秒，基本不会影响Zabbix的正常写入。

重要提示：MySQL的OPTIMIZE TABLE在执行时会重建整个表，磁盘需要有足够的临时空间，并且表会被锁住。如果表已经占了500GB，磁盘只剩50GB，OPTIMIZE TABLE大概率会失败。这种极端情况下，建议直接评估分区方案或迁移TimescaleDB。

3.3 调整Zabbix侧配置，从源头控制数据量

紧急删完数据之后，如果不改配置，过几周又会恢复原样。所以第二步就是调整Zabbix的数据保留策略。这个配置在前端页面就能操作：

Administration → General → Housekeeping

关键参数就两个：

• History storage period（历史数据保留周期）：建议按你的实际回查需求设置，一般14天到30天足够。
• Trend storage period（趋势数据保留周期）：趋势数据体积小，可以保留时间长一些，比如180天到365天。

很多人不知道这里的配置是针对所有监控项全局生效的。如果你想让某些监控项单独设更短周期，可以在监控项层面覆盖，但日常运维中全局配置已经能解决绝大多数问题。

另外前端Housekeeping设置里，要确认“Housekeeping”的开关是启用的，并且没有勾选“Override item history period”导致某些监控项被设置成了无限期保存。我遇到过一次：某台主机的某个监控项在模板里单独设置了History为0，0在Zabbix里代表不存储历史数据，但有些监控项被设成了36500天，等于永久保存，直接把表撑爆了。排查这个问题花了我不少时间。

3.4 长期治理：分区表方案

如果你希望一劳永逸，分区表是当前Zabbix + MySQL场景下最成熟的方案。

分区的思路特别简单：一张大表按时间拆成多个小分区，比如按天分区，每天一个分区。历史数据要清理的时候，不再是执行DELETE一条一条删除，而是直接把过期的分区整个DROP掉。DROP分区是元数据操作，秒级完成，和DELETE几千万行数据完全是两个量级。

先看你的MySQL版本是否支持分区（MySQL 5.7+都支持），然后用下面的方式改造history_uint表：

-- 对history_uint表启用按天分区 ALTER TABLE history_uint PARTITION BY RANGE (UNIX_TIMESTAMP(FROM_UNIXTIME(clock))) ( PARTITION p20240101 VALUES LESS THAN (UNIX_TIMESTAMP('2024-01-02 00:00:00')), PARTITION p20240102 VALUES LESS THAN (UNIX_TIMESTAMP('2024-01-03 00:00:00')), PARTITION p20240103 VALUES LESS THAN (UNIX_TIMESTAMP('2024-01-04 00:00:00')) );

不过手工写分区语句太痛苦，实际操作中一般都配合定时脚本，每周自动创建未来一周的分区，并且删除一个月前的分区。社区里有一个很出名的脚本叫zabbix-mysql-partitioning，可以直接拿过来用，它支持按小时、按天、按月分区，也支持配置保留多少个分区。

脚本的核心逻辑分三块：

1. 定期为history*和trends*表创建新的未来分区；
2. 定期删除过期分区；
3. 维护一个分区的“保留清单”，避免一次删过头。

用cron定时跑：

# 每天凌晨1点执行分区维护脚本 0 1 * * * /opt/scripts/zabbix_partition.sh >/dev/null 2>&1

这个方案我实测下来的效果是：单张10亿行级别的history_uint表，分区后每天的数据量几千万行，清理老数据从以前的小时级变成秒级。你只需要确保定时脚本稳定运行，磁盘占用就不会再无限膨胀。

3.5 长期治理升级版：PostgreSQL + TimescaleDB

如果你的Zabbix版本是5.0以上，并且愿意迁移到PostgreSQL，那TimescaleDB是当前体验最好的长期方案。Zabbix官方从5.0开始对TimescaleDB做了很好的适配，6.0以后的版本集成度更高。

TimescaleDB的核心概念是hypertable（超表）。它把一个大表自动按时间切成很多chunk，底层自动管理。你不需要像MySQL那样手动建分区、手动删分区，只需要创建好超表，后面的按时间清理都由TimescaleDB的drop_chunks策略自动完成。

使用TimescaleDB，最核心的几步：

-- 创建TimescaleDB扩展 CREATE EXTENSION IF NOT EXISTS timescaledb; -- 把已有的history_uint表转换为超表 SELECT create_hypertable('history_uint', 'clock', chunk_time_interval => INTERVAL '1 day'); -- 添加自动清理策略：保留30天数据 SELECT add_retention_policy('history_uint', INTERVAL '30 days');

你看看这对比，手动分区时你要写脚本创建分区、删除分区；TimescaleDB里两行SQL就把自动化保留策略配置完了。而且TimescaleDB的压缩功能还可以把旧数据压缩存放，磁盘占用能再降一个量级。我在生产环境里用chunk_time_interval => '1 day'，加上压缩策略，单台Zabbix服务器撑住上万监控项毫无压力。

提示：从Zabbix 6.0开始，官方安装文档明确推荐使用TimescaleDB。如果你的环境是全新搭建，直接用PostgreSQL + TimescaleDB是最省心的路线。如果是存量MySQL环境，可以考虑渐进式迁移，先把trends库迁移过去，再把history迁移过去。

3.6 策略级优化：有些数据根本不需要进history

最后这条很多人会忽略：Zabbix里不是所有监控项都必须存历史数据，很多监控项你可以选择“只存趋势、不存历史”，甚至“采集后立即销毁”。

举个例子：某个监控项只是为了做告警阈值判断，你不关心它的历史曲线，那就可以在监控项配置里把History设成0。这样数据采集后只参与告警判断，不会写入history表。这个配置会极大减少无效数据。

另外Preprocessing（预处理）功能也能减少存储量。比如一个设备每次返回一个JSON，如果你的告警逻辑只需要其中某个字段，可以用JSONPath把字段提取出来再存储，而不是把整个原始内容写入history_str。这样既能保留有效数据，又能让存储占用大幅下降。

还有一个实践是调低非关键监控项的采集频率。比如：

• 核心业务指标：30秒采集一次，保留30天
• 普通系统指标：5分钟采集一次，保留14天
• 网络流量类指标：1分钟采集一次，保留30天

用这个思路去梳理你的监控项模板，你会发现采集总量能下降一半以上。数据都少采了，表自然就不会膨胀到让数据库报警的程度。

4. 一次完整的清理实操复盘

4.1 环境现状与问题表现

下面我用一个模拟案例，把前面说的方案串成一条完整的操作主线，方便你直接“抄作业”。

假设环境是这样的：

• Zabbix版本：6.0 LTS
• 数据库：MySQL 8.0，数据目录挂在/data分区下
• 监控规模：500台主机，约2万个监控项
• 症状：磁盘使用率97%，history_uint表占了670GB，Zabbix前端开始出现“Zabbix server is not running”的告警，监控数据出现断档

这个场景特别典型：数据库磁盘满了以后，Zabbix Server写不进数据库，前端就会报server is not running，同时告警媒介（比如钉钉联动）也会失效。处理优先级是：先腾出空间保住服务，再做长期方案。

4.2 第一步：紧急清理，腾出磁盘空间

先确认当前zabbix库里的数据总量：

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb FROM information_schema.tables WHERE table_schema = 'zabbix' ORDER BY data_length + index_length DESC LIMIT 10;

结果排名第一的是history_uint，670GB；第二是history，180GB。两块加起来快850GB，不处理几天内磁盘就会写满。

果断执行分批删除，目标是把history相关的数据保留周期压缩到7天。由于history表里的数据还在持续写入，我先把Zabbix Server短暂停掉，避免边删边写导致更多锁表问题。

systemctl stop zabbix-server

然后用循环分批DELETE：

-- 分批删除10天前的history_uint数据 DELETE FROM history_uint WHERE clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 10 DAY)) LIMIT 500000;

反复执行这条语句，直到影响行数为0。大概执行了40多批，总共删掉约2亿行。然后对history、history_uint、history_str、history_log都执行同样的清理。

清理完毕后启动Zabbix Server：

systemctl start zabbix-server

4.3 第二步：OPTIMIZE表释放磁盘空间

数据删掉之后，InnoDB的表文件不会自动缩小，磁盘空闲空间并没有真正释放出来。必须对表执行OPTIMIZE TABLE，把表和索引重建一遍，让数据文件缩回到当前数据量对应的大小。

OPTIMIZE TABLE history_uint; OPTIMIZE TABLE history; OPTIMIZE TABLE trends_uint; OPTIMIZE TABLE trends;

这一步执行时间取决于表大小。670GB的表优化可能要跑1个多小时。最好在低峰期执行，并且要看着磁盘剩余空间，确保有足够空间完成临时表创建。

优化完之后再看磁盘空间，你会发现数据文件明显缩水，原来的850GB降到了160GB左右，磁盘使用率回落到60%以下，前端也恢复了正常。

4.4 第三步：配置层面防止快速回弹

临时清理只能救急，接下来马上修改前端Housekeeping配置：

Administration → General → Housekeeping

• History storage period：改成14d
• Trend storage period：改成180d

同时把Zabbix Server的housekeeper频率参数确认一下，配置文件zabbix_server.conf里的HousekeepingFrequency默认是1小时，也就是每1小时执行一次历史数据清理。如果发现history表里老数据删除缓慢，可以把频率调高：

HousekeepingFrequency=1

4.5 第四步：落地分区方案

为了以后不再手动删数据，我在这套环境里实施了MySQL分区方案。考虑到数据量，我选择按月分区，每个月的分区包含一个月的数据，并配置脚本自动创建下个月分区、删除6个月前的分区。

脚本设计核心逻辑大致如下：

#!/bin/bash # zabbix_monthly_partition.sh # 为history_uint创建下个月分区，删除6个月前的分区 DB_USER='zabbix' DB_PASS='password' DB_NAME='zabbix' # 创建下个月分区 NEXT_MONTH=$(date -d "+1 month" +%Y%m) NEXT_MONTH_START=$(date -d "+1 month" +%Y-%m-01) NEXT_MONTH_END=$(date -d "+2 months" +%Y-%m-01) # 计算UNIX时间戳 START_TS=$(date -d "$NEXT_MONTH_START" +%s) END_TS=$(date -d "$NEXT_MONTH_END" +%s) mysql -u$DB_USER -p$DB_PASS $DB_NAME -e " ALTER TABLE history_uint ADD PARTITION ( PARTITION p$NEXT_MONTH VALUES LESS THAN ($END_TS) ); "

删除旧分区的操作也放进脚本，通过cron每月1号执行。注意，分区表里的历史数据是分块存在的，删除分区时，如果该表还有其他保留策略，会按分区的键进行判断。脚本的思路就是用时间键来判断是否过期。

这个方案上线后，我再也没有为history表手动跑过DELETE。后来我把这套环境迁移到了TimescaleDB，清理策略更是完全自动化，磁盘空间长期稳定。

4.6 第五步：验证监控数据完整性

清理和优化配置之后，一定要到前端页面验证一下数据看板和告警是否正常：

• 查看最新数据是否持续更新（最新数据页面能看到每个主机的采集时间）
• 查看图形页面，确认历史曲线有数据、趋势图也能画出来
• 查看队列页面，确认没有大量数据等待被处理
• 发送一条测试告警，确认告警通道正常

如果图形页面点开是白的，先检查housekeeper是否把数据删过头了，再检查监控项的History存储时间设置。很多时候不是因为清理导致空白，而是因为采集停了太久，或者存储设置本来就是0。

5. 常见问题与排查技巧实录

5.1 数据清理了，磁盘空间为啥没释放

这是问得最多的问题。原因就是InnoDB删除数据只是打标记，物理文件不会缩小。解决方案就是我前面说的OPTIMIZE TABLE。如果表非常大，你可以考虑ALTER TABLE ... ENGINE=InnoDB来重建表，效果类似，但要评估锁表影响。

还有一个办法是从源头杜绝碎片：直接用分区表。每天/每月一个分区，过期分区直接DROP PARTITION，文件收缩立竿见影，根本不需要OPTIMIZE TABLE。

5.2 DELETE删数据导致数据库卡死

我见过不止一次，有人直接在几亿行的表上执行全量DELETE，然后把数据库锁死了。解决办法：

• 停掉Zabbix Server再清理
• 分批次LIMIT删除
• 尽量删除“时间更早”的数据，减少对最新写入的影响
• 如果用的是ClickHouse/TimescaleDB这类带分区特性的存储，更推荐用DROP分区而不是DELETE

5.3 housekeeper为什么不删历史数据

Housekeeper是Zabbix里的一个内部进程，负责定期清理过期数据。如果你的history表一直不瘦身，排查方向：

1. 前端Housekeeping配置是否启用了对应的History/Trends清理开关；
2. zabbix_server.conf里HousekeepingFrequency是否为0（0代表禁用）；
3. 数据库里大多数历史数据还没到保留期限；
4. 监控项数量太大，housekeeper每轮清理量有限，跟不上新增速度。

如果是因为容量太大，建议把保留周期调短，并且用分区表辅助清理，而不是单纯依赖housekeeper。

5.4 清理后磁盘依然告警，根因在binlog或备份文件

有时候你清理了history表，磁盘空间还是不够。这种情况不要把注意力全放在表数据上，还要检查：

• MySQL binlog日志有没有设置自动过期（expire_logs_days或binlog_expire_logs_seconds）；
• Zabbix前端有没有定期生成备份文件，备份文件是否存放在数据盘；
• 慢查询日志、general log是否开启且体积膨胀。

我在生产环境里就遇到过：history表只占300GB，但是binlog累计了500GB，直接把磁盘干爆了。所以排查一定要全面，别只盯着数据库表。

5.5 Zabbix Server状态异常，前端报“Zabbix server is not running”

很多情况下，这个报错不是Zabbix服务本身挂了，而是数据库写入失败导致的连锁反应。尤其是磁盘空间不足、数据库连接池耗尽、慢查询堆积时，Zabbix Server虽然进程活着，但写不进数据，前端就会报这个错。

如果你在清理完数据后还看到这个提示，重点检查：

• MySQL连接数是否被打满；
• Zabbix Server日志里有没有数据库连接失败的报错（比如Access denied for user ...）；
• 磁盘空间是否真的释放成功。

5.6 清理后部分图形数据为空

有一种情况是：你把历史保留周期改成7天，趋势保留周期改成180天，然后发现有些图形7天之前的数据查不出来了。这是正常的，因为历史数据已经被清掉，曲线只能显示趋势数据（聚合值）。如果是业务需要，可以单独给核心监控项设置更长的历史保留时间。

写在最后：我的几点实操体会

说实话，Zabbix的history表膨胀并不是一个“删一次就完事”的问题，它本质上暴露的是监控系统设计阶段的存储规划缺陷。我个人的体会是，处理这类问题一定要遵循三个原则：

第一，先保服务，再治数据。磁盘满的时候优先停掉采集、释放空间，让Zabbix恢复正常运行，再做长期方案，不要一上来就想着优化架构。

第二，数据保留时间不是越长越好。很多团队不敢删历史数据，怕查不到记录。实际上Zabbix有trends作为长期趋势数据的兜底，历史原始数据保留两周到一个月已经足够排查问题。如果你的业务确实需要长期保存原始数据，应该用归档方案，而不是让它无限膨胀在在线数据库里。

第三，能自动化的不要手工做。手动DELETE只是应急，最终一定要落到分区表或TimescaleDB上，让数据清理变成自动化的周期任务。否则你每隔一两个月就要半夜起来删数据，日子真的没法过。

如果你用的是MySQL环境，我建议今天就去看一眼zabbix库的表大小和housekeeper配置。如果已经出现了较大占用，尽快规划分区方案，别等磁盘告警了再着急。如果你还没有部署Zabbix，或者在规划新环境，直接上PostgreSQL + TimescaleDB，你会省下后面很多麻烦。