简介这份PDF操作记录围绕Zabbix 7.0 LTS的MySQL/MariaDB数据库分区优化展开针对历史记录表与趋势表数据膨胀、housekeeper进程繁忙告警等常见问题提供了完整的分区实施方案。文档详细讲解了下载并解压zbx_db_partitiong.sql分区脚本、通过命令行创建分区存储过程、利用MySQL事件调度器或Crontab定期自动执行分区以及在Zabbix前端调整历史与趋势保留天数等关键步骤并给出修改默认分区天数如7天历史、365天趋势的具体方法。资源共1个PDF文件压缩包大小835KB内容精炼适合已有一定Zabbix基础、希望提升数据库性能并降低维护成本的运维人员参考。目前已有354人学习下载该教程适用于Zabbix 3.0及之后所有版本实施前建议先备份数据库对大型库执行分区操作时也需预留充足时间。1. Zabbix 7.0 LTS 到底值不值得升这次部署要解决的两件事Zabbix 7.0 LTS 发布以后最热闹的讨论其实不是新功能而是“升级后数据库怎么办”。我用 5.0、6.0 一路挪到 7.0 的实际体感是前端确实顺了Agent 2 的加密和自带采集器也省事不少但真正决定这套平台是“能用”还是“稳稳能用”的分水岭是部署完有没有第一时间把 history、history_uint、trends 这些写入最猛的表做分区。这篇文章按常见的生产路径来走Rocky Linux 9 / CentOS 9 系列系统 MySQL 8.0 装好 Zabbix 7.0 LTS再带着分区脚本和踩坑记录把数据库优化这块补完。适合正在新建监控平台、或者准备从旧版本迁过来又怕业务中断的运维同学也适合那些已经被 Housekeeper 慢删搞到半夜爬起来清表的兄弟。2. 从零部署 Zabbix 7.0 LTSRocky Linux 9 / CentOS 9 MySQL 8.0 的最小可运行路径2.1 选型理由为什么是 MySQL 8.0为什么不用系统自带源先回答一个最常见的疑问CentOS 上自带 MariaDB能不能直接拿来跑 Zabbix 7.0 LTS能跑但我不会在生产环境这么干。Zabbix 官方对 7.0 LTS 的主要支持组合是 MySQL 和 PostgreSQL官方测试脚本、分区经验、社区踩坑记录都围绕这两个走MariaDB 虽然语法接近但在分区维护、全文索引、查询优化器行为上都有细微差异出了问题你很难判断是 Zabbix 的锅还是数据库的锅。再一个原因是 MySQL 8.0 对 RANGE 分区的在线维护比旧版本稳定而且支持直接ALTER TABLE ... ADD PARTITION这种秒级元数据操作。监控平台的数据模型本来就是“按时间写入、按时间删除”MySQL 8.0 的 RANGE 分区配合DROP PARTITION正好对上了 Zabbix 的清理需求。至于系统源里的 MySQL 版本常见做法是直接用官方 rpm 源把dnf仓库切到 mysql80 社区版保证拿到的是 8.0.x 而不是 AppStream 里某些裁剪版。环境基准我建议是 Rocky Linux 9 或者 CentOS 9 Stream银河麒麟系统 v10 上部署 Zabbix 7.0 的逻辑也一样先把 el9 的官方 repo 拉下来再用dnf安装。MySQL 端需要 2GB 以上内存才跑得舒服Zabbix server 和数据库在同一台机器上时建议内存不低于 8GB否则前端图表聚合查询会明显吃紧。2.2 MySQL 8.0 安装与初始化先初始化再装 Zabbix 的固定顺序先把 MySQL 官方 repo 装上。不同系统的仓库包不一样el9 就用 el9 的版本不要拿 el8 的硬怼 el9依赖会缺一堆。# 安装 MySQL 官方社区版仓库然后直接装 server sudo rpm -Uvh https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm sudo dnf install -y mysql-community-server # 启动并查看临时密码mysqld.log 里会打印一次 sudo systemctl enable --now mysqld sudo grep temporary password /var/log/mysqld.log这里有个顺序坑必须先启动 MySQL 完成初始化再执行mysql_secure_installation改密码顺序反了会导致后续 Zabbix 建库时权限验证总是失败。临时密码只在首次启动的日志里出现一次如果没抓到可以rm -rf /var/lib/mysql重新初始化但生产环境不建议直接ALTER USER重置即可。初始化完成后用 root 登录建库建用户。字符集和排序规则必须固定我一般用utf8mb4配utf8mb4_bin。官方 schema 里涉及 item 名称、宏名称的比较用utf8mb4_bin能避免大小写敏感不一致导致的索引长度超限问题。-- 建库、建用户、授权密码请自行替换 CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER zabbixlocalhost IDENTIFIED BY YourStrongPassword; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; FLUSH PRIVILEGES;接着把my.cnf里的几个核心参数写了再重启。sql_mode这里我特意去掉了NO_ZERO_DATE因为 Zabbix 官方导入脚本里存在0000-00-00这种默认值默认的严格模式直接会让导入语句报错。这个问题在部署当天不炸导入 schema 时必炸。[mysqld] innodb_buffer_pool_size 8G innodb_file_per_table ON character-set-server utf8mb4 collation-server utf8mb4_bin sql_mode STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION2.3 Zabbix server 安装与数据库导入一条命令一个坑Zabbix 7.0 LTS 官方仓库还是老套路先装 release rpm再dnf install。这里我把 server、数据库脚本、selinux 策略、agent2 一次装齐避免后面补包。# 安装 Zabbix 7.0 LTS 官方仓库并安装 server 组件 sudo rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-7.0-1.el9.noarch.rpm sudo dnf install -y zabbix-server-mysql zabbix-sql-scripts zabbix-selinux-policy zabbix-agent2 # 导入官方 schemaserver.sql.gz 解压后直接管道到 mysql sudo zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-setutf8mb4 -uzabbix -pYourStrongPassword zabbix导入这里是最耗耐心的环节。schema 文件包含数百张表的建表语句正常一两分钟完成。如果中途报错先别急着重跑去 tail/var/log/mysql/mysqld.log看是权限问题还是sql_mode问题。常见坑是ERROR 1067 (42000): Invalid default value for clock这类错误基本都是NO_ZERO_DATE惹的祸。导入完成后修改/etc/zabbix/zabbix_server.conf重点确认下面四行DBHostlocalhost DBNamezabbix DBUserzabbix DBPasswordYourStrongPassword配置文件默认权限是 root 组密码明文写在里面建议保持0640权限别乱改。保存后systemctl restart zabbix-server然后用tail -f /var/log/zabbix_server.log盯启动日志。看到server #0 started字样就说明数据库连接没问题否则八成是密码或主机名解析问题。2.4 Nginx PHP-FPM 前端与首次初始化向导Zabbix 7.0 的前端推荐用 Nginx 而不是 Apache包名叫zabbix-nginx-conf安装后它在/etc/nginx/conf.d/zabbix.conf里生成了一份默认配置。这份配置默认监听 8080 端口并且 PHP-FPM 的 socket 路径必须和zabbix.conf里fastcgi_pass声明一致。sudo dnf install -y zabbix-web-mysql zabbix-nginx-conf sudo systemctl enable --now nginx php-fpmzabbix-web-mysql这个包会把 PHP 相关配置放到/etc/php-fpm.d/zabbix.conf里面预置了时区和内存限制。我一般会再手动确认几项php_value[memory_limit] 256M、php_value[post_max_size] 16M、php_value[max_execution_time] 300。特别是date.timezone默认留空会导致前端安装向导在检查环境时直接红字提示。浏览器访问http://服务器IP/zabbix进入安装向导数据库信息填 zabbix 和对应密码下一步就完成初始化。这一步几乎不会出幺蛾子唯一的坑是如果你在前面建库时用了utf8mb4_0900_ai_ci而不是utf8mb4_bin向导里检查字符集会给你一个黄色警告不影响安装但建议回炉重来。到这里Zabbix 7.0 LTS 已经跑起来了。但我要泼一盆冷水这只是一半工作。安装完成不等于交付完成接下来数据库分区不做这套平台在 500 台主机以下还能扛上千台以后你会被慢 SQL 拖死。3. 数据库分区优化history 与 trends 表的性能瓶颈为什么必须靠分区解决3.1 不分区时 Zabbix 会遇到什么表膨胀、Housekeeper 慢、慢 SQL我见过不止一个团队在 Zabbix 上栽在同一件事监控跑了一个季度磁盘突然报警登录数据库一看history_uint表已经 200 多 GBtrends表也有 80GB。这就是没有分区的典型症状——历史数据全部堆在同一个 InnoDB 表里。Zabbix 自身的清理机制叫 Housekeeper它会定期执行 DELETE 删除过期历史数据。问题在于对于几十 GB 的大表DELETE 一条记录要维护二级索引和聚簇索引删除 100 万行往往要跑几十分钟甚至几个小时。期间information_schema统计信息过期、binlog 暴涨、主从延迟、临时文件占满/tmp最要命的是 DELETE 和采集写入并发时产生锁竞争直接影响监控数据入库。慢 SQL 优化在这里是有边界的:你给history_uint加再好的索引数据量到了亿级范围查询和删除依然要扫描大量 B 树节点。而分区表的思路完全不同:按月或者按天把数据切成若干独立的子表查询只扫命中分区清理直接 DROP 整个分区。一个ALTER TABLE history_uint DROP PARTITION p20250401是元数据操作秒级完成这才是数据库分区优化的核心价值。3.2 分区策略设计history 按天、trends 按月、保留窗口先想清楚再动手分区粒度的设计原则很简单写入越频繁的表分区越细聚合数据变化慢分区可以放宽。Zabbix 7.0 的 history 系列表history、history_uint、history_str、history_log是秒级写入按天分区是主流trends和trends_uint是小时级聚合按月分区就够alerts表量不大按天或按月都行。我推荐一个起步策略history 系列保留 14 天trends 保留 400 天alerts 保留 180 天。这个窗口兼顾了短周期排障和年度趋势分析磁盘成本也压得住。如果你业务上必须看 90 天的原始监控曲线那 history 保留期拉长到 90 天但分区数量会从 14 涨到 90后面open_files_limit的坑你就必须提前避开。分区的字段用clock这是 Zabbix 每条历史记录在采集时写入的 unix 时间戳类型是bigint unsigned。分区方式选 RANGE因为 RANGE 分区天然支持“按时间边界裁剪”HASH 分区虽然散列均匀但没办法按时间批量 DROP等于把清理能力废掉了。3.3 手写一次分区把已有数据分区而不是等它膨胀对刚部署的 Zabbix 7.0数据量还小时直接改表结构是最佳窗口期。先看history_uint的建表结构你会发现这张表没有主键只有一个history_uint_1二级索引。不要自己补主键——如果加了主键分区键必须包含在主键里RANGE(clock) 直接报错。正确做法是直接对整表分区-- 已有数据表在线改为 RANGE 分区按天切分 ALTER TABLE history_uint PARTITION BY RANGE (clock) ( PARTITION p20250501 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-02 00:00:00)), PARTITION p20250502 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-03 00:00:00)), PARTITION p20250503 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-04 00:00:00)), PARTITION p20250504 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-05 00:00:00)), PARTITION p20250505 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-06 00:00:00)), PARTITION p20250506 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-07 00:00:00)), PARTITION p20250507 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-08 00:00:00)), PARTITION p20250508 VALUES LESS THAN (UNIX_TIMESTAMP(2025-05-09 00:00:00)) );注意两个细节。第一每个分区的边界是“下一天零点”的时间戳p20250501装的是 5 月 1 日 0 点到 5 月 2 日 0 点之间的数据分区名是当天日期边界值却是明天的零点这很容易记反。第二ALTER TABLE ... PARTITION BY RANGE是一次全表重建不是秒级操作。如果你的 history_uint 已经有 50GB 数据这个语句在低峰期执行也要 20 分钟以上期间表是只读的。所以要赶在数据量小的时候做这是我把这一步放在部署章节里的原因。history、history_str、history_log三张表结构不同但分区方式完全一致照抄同一套语句就行。trends总数据量小按月的分区语句长这样边界值是下月 1 号零点ALTER TABLE trends PARTITION BY RANGE (clock) ( PARTITION p202505 VALUES LESS THAN (UNIX_TIMESTAMP(2025-06-01 00:00:00)), PARTITION p202506 VALUES LESS THAN (UNIX_TIMESTAMP(2025-07-01 00:00:00)), PARTITION p202507 VALUES LESS THAN (UNIX_TIMESTAMP(2025-08-01 00:00:00)) );手工分区只能在部署当周用因为运维不可能每周半夜爬起来敲 SQL。下一步就是把创建分区和清理分区的逻辑写成存储过程交给 cron 去执行。4. 自动化分区脚本创建未来分区与清理过期分区两条流水线4.1 CreatePartitions把未来 7 天的 history 分区建好自动化的第一条流水线是“向前建分区”。我写的存储过程接收表名和提前天数从今天开始往后逐天生成pYYYYMMDD分区边界取第二天的零点。分区已经存在时会跳过不会重复执行。DELIMITER $$ CREATE PROCEDURE CreateDailyPartitions(IN _table_name VARCHAR(64), IN _days_ahead INT) BEGIN DECLARE _i INT DEFAULT 0; DECLARE _day DATETIME; DECLARE _next_day DATETIME; DECLARE _part_name VARCHAR(16); DECLARE _upper_bound BIGINT; DECLARE _exists INT; DECLARE _sql_text VARCHAR(2048); WHILE _i _days_ahead DO -- 从今天开始逐天生成分区名与边界 SET _day DATE_ADD(CURDATE(), INTERVAL _i DAY); SET _next_day DATE_ADD(_day, INTERVAL 1 DAY); SET _part_name CONCAT(p, DATE_FORMAT(_day, %Y%m%d)); SET _upper_bound UNIX_TIMESTAMP(_next_day); -- 检查该分区是否已存在存在则跳过 SET _exists ( SELECT COUNT(*) FROM information_schema.partitions WHERE table_schema DATABASE() AND table_name _table_name AND partition_name _part_name ); IF _exists 0 THEN SET _sql_text CONCAT( ALTER TABLE , _table_name, ADD PARTITION (PARTITION , _part_name, VALUES LESS THAN (, _upper_bound, )) ); SET sql _sql_text; PREPARE stmt FROM sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; END IF; SET _i _i 1; END WHILE; END$$ DELIMITER ;逻辑很简单循环里先算好分区名和边界值然后查information_schema.partitions判断是否已存在最后动态拼接ALTER TABLE ... ADD PARTITION并执行。注意边界值用UNIX_TIMESTAMP(_next_day)拿到的是次日零点的秒数和手工分区的写法保持一致。调用时把 Zabbix 的几张 history 表都过一遍建议把_days_ahead设为 7也就是最多提前建一周内的时间窗口CALL CreateDailyPartitions(history_uint, 7); CALL CreateDailyPartitions(history, 7); CALL CreateDailyPartitions(history_str, 7); CALL CreateDailyPartitions(history_log, 7);trends 表按月分区单独写一个按月版本原理完全一样只是DATE_FORMAT(_day, %Y%m)生成p202505这种分区名提前量按月份算。4.2 DeleteOldPartitions按 DROP 一步清理过期分区第二条流水线是“向后删分区”。核心是从分区名反推日期比如p20250401就是 2025 年 4 月 1 日。用游标扫出所有小于保留天数的分区然后逐个 DROP。这个操作的执行代价远低于 DELETE因为 DROP PARTITION 只删除磁盘文件段。DELIMITER $$ CREATE PROCEDURE DeleteOldPartitions(IN _table_name VARCHAR(64), IN _keep_days INT) BEGIN DECLARE _part_name VARCHAR(16); DECLARE _done INT DEFAULT 0; DECLARE _sql_text VARCHAR(2048); -- 游标找出所有分区日期早于当前日期减保留天数的分区 DECLARE cur_part CURSOR FOR SELECT partition_name FROM information_schema.partitions WHERE table_schema DATABASE() AND table_name _table_name AND partition_name IS NOT NULL AND STR_TO_DATE(SUBSTRING(partition_name, 2), %Y%m%d) DATE_SUB(CURDATE(), INTERVAL _keep_days DAY); DECLARE CONTINUE HANDLER FOR NOT FOUND SET _done 1; OPEN cur_part; partition_loop: LOOP FETCH cur_part INTO _part_name; IF _done 1 THEN LEAVE partition_loop; END IF; -- 动态拼接删除语句注意 DROP PARTITION 可以一次删多个 SET _sql_text CONCAT(ALTER TABLE , _table_name, DROP PARTITION , _part_name); SET sql _sql_text; PREPARE stmt FROM sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; END LOOP; CLOSE cur_part; END$$ DELIMITER ;这段有个小技巧SUBSTRING(partition_name, 2)把分区名p20250401前面的p剥掉剩下20250401再用STR_TO_DATE转成日期。这样即使你忘了今天是几号MySQL 也会按分区名自动判断哪些过期。如果某个分区名不是标准的pYYYYMMDD格式转换会返回 NULL游标条件自然跳过不会误删。月度分区的trends表调用逻辑一样只是传入的保留天数按天算我一般传 400 天对应 13 个月的月度分区。4.3 用 MySQL 事件调度器还是 cron两种调度方式的取舍存储过程写好了接下来是调度问题。MySQL 自带事件调度器CREATE EVENT DailyPartitionMaintenance ON SCHEDULE EVERY 1 DAY ...就能每天自动跑。但我推荐用 cron原因是在 Zabbix 这种对时序敏感的监控场景里数据库和监控可能同时故障事件调度器跟着 MySQL 一起消失的时候你根本不知道;而 cron 由 systemd 管理日志独立出问题还能从/var/log/cron里翻。我一般会把脚本放到/usr/local/bin/zabbix_partition_maintain.sh内容如下#!/usr/bin/env bash # Zabbix 7.0 LTS 数据库分区日常维护 # 使用 --defaults-extra-file 避免密码出现在进程列表中 MYSQL_OPTS--defaults-extra-file/etc/mysql/zabbix.cnf mysql $MYSQL_OPTS -e CALL CreateDailyPartitions(history_uint, 7); CALL CreateDailyPartitions(history, 7); CALL CreateDailyPartitions(history_str, 7); CALL CreateDailyPartitions(history_log, 7); CALL DeleteOldPartitions(history_uint, 14); CALL DeleteOldPartitions(history, 14); CALL DeleteOldPartitions(trends_uint, 400);对应的zabbix.cnf内容就是四行[client] hostlocalhost userzabbix passwordYourStrongPassword这个文件权限必须设成 600一行命令把密码写在-p后面的做法不规范ps能看到进程参数就等于明文裸奔。crontab 里每天凌晨 1 点半跑一次正好避开监控采集高峰30 1 * * * root /usr/local/bin/zabbix_partition_maintain.sh /var/log/zabbix_partition.log 214.4 3 个必调的关联参数innodb_file_per_table、open_files_limit、binlog分区不是加完存储过程就结束MySQL 侧有三个参数不调前面所有工作都会在数据量上来后反噬你。第一个是innodb_file_per_table ON。这个在 MySQL 8.0 默认就是开的但如果你在旧版本迁移时改了配置必须确认它开着。它的作用是让每个分区拥有独立的.ibd文件这样DROP PARTITION才能直接释放磁盘空间。如果关着所有分区数据混在同一个表空间里DROP 只删逻辑数据物理文件不会变小。第二个是open_files_limit。按天分区的 history 系列表一年就是 360 多个分区文件加上每张表还有其他 ibd 文件很容易触到文件句柄上限。报错特征是日志里出现Too many open files。我建议在my.cnf里显式写上open_files_limit 65535同时把 systemd 的LimitNOFILE也调上去否则配置只对命令行的 mysqld 生效systemd 启动的实例会忽略。第三个是 binlog 策略。Zabbix 数据库通常是单机部署不用开主从但如果你开了 binlog每天晚上 DROP 几十个分区会产生不小的 DDL 记录。分区清理本身是元数据操作不会导致主从数据不一致所以真正要关注的是保留策略建议expire_logs_days 7别让 binlog 把磁盘吃掉。5. 部署和分区过程中的常见问题避坑现象、原因与解决办法5.1 导入 schema 时报 SQL 语法错误sql_mode 的 NO_ZERO_DATE 在作怪现象zcat server.sql.gz | mysql导入时报错日志显示ERROR 1067 (42000): Invalid default value导入中断数据库里只建了一半表。原因Zabbix 官方 schema 里部分表字段默认值写的是0000-00-00MySQL 8.0 默认的 sql_mode 打开了NO_ZERO_DATE和NO_ZERO_IN_DATE直接拒绝这种默认值。解决导入前临时把 sql_mode 里的这两个项去掉。最稳妥的姿势是修改my.cnf里的sql_mode配置重启再导入导入完可以保留这个配置因为 Zabbix 后续运行并不依赖严格零日期检查。5.2 新数据写不进去报 1526/1630分区没覆盖当前时间现象Zabbix server 日志大量报ERROR 1526 (HY000): Table has no partition for value ...前端图表全部断档新采集的数据进不了库。原因RANGE 分区要求写入数据的clock值必须落在某个已有分区的区间内。如果自动建分区的 cron 挂了或者分区只建到“昨天”当前时刻的写入就会因为没有对应分区而被拒。解决立即手工补建后续几天的分区或者直接跑一次CALL CreateDailyPartitions(history_uint, 3)。日常运维建议在监控项里加一条自定义脚本每天检查information_schema.partitions里最大分区边界是否大于CURDATE() 1异常时告警这样不用等前端图表断了才后知后觉。5.3 ALTER TABLE 加分区卡死十几分钟在线 DDL 与表备份取舍现象第一次给history_uint执行PARTITION BY RANGE时命令执行了 20 分钟还没结束前端断图业务方来问是不是数据库挂了。原因ALTER TABLE ... PARTITION BY RANGE属于表重建操作InnoDB 要逐行读取旧表并写入新结构数据量越大耗时越长期间表上 DML 会被阻塞。这和分区建好之后ADD PARTITION的秒级操作完全不同。解决首次分区必须选低峰期执行。执行前预估表大小准备好至少表大小两倍的临时空间InnoDB 重建会复制一份。如果实在不能接受停机窗口那就别等表膨胀了——部署当天数据量最小的时候做这是所有方案里后悔药最少的一种。5.4 分区后磁盘空间没释放文件句柄和 information_schema 统计现象执行完DeleteOldPartitions后df -h显示磁盘空间几乎没变化运维怀疑脚本删了个寂寞。原因两种可能。第一是innodb_file_per_tableOFF分区数据混在系统表空间里DROP 分区只逻辑删除不物理释放;第二是 InnoDB 后台线程还没有把脏页刷盘或者删的是分区文件而系统还没更新可用块数。解决先看df -h是否在几分钟后下降如果没有检查innodb_file_per_table。确认打开后对目标表执行ALTER TABLE xxx ENGINEInnoDB重建表来收缩表空间但这个操作同样要选低峰期。以后每天的清理工作都会做 DROP PARTITION只要参数正确空间释放是准时的。5.5 服务器时间跳变杀掉监控数据触发器和“精准时钟”的依赖关系现象某台机器 NTP 回拨或者手动改时间后Zabbix 历史数据突然断片查数据库发现最大分区的边界已经覆盖不到当前时间或者分区名日期乱序。原因分区脚本里的CURDATE()和UNIX_TIMESTAMP()都依赖 MySQL 服务器当前时间。如果时间向前跳分区边界整体前移之前按旧时间建的分区覆盖不到新时间戳的写入如果时间向后跳新建的分区日期和已有分区重叠ADD PARTITION直接报Duplicate partition name。解决监控服务器的时钟必须统一交给 NTP 管理禁止业务侧手动调时间。同时分区边界计算建议统一用 UTC避免夏令时和时区偏差带来的边界错位。MySQL 连接里执行SET time_zone 00:00或者在建存储过程前把/etc/my.cnf的default-time-zone配好能少掉九成时间相关的灵异事件。6. 验收用 information_schema 和 EXPLAIN 确认分区被真正命中分区做完不是靠感觉说“快了”要拿数据证明。第一步查information_schema.partitions确认分区数量和边界正确SELECT table_name, partition_name, partition_method, CONCAT(FROM_UNIXTIME(partition_description - 86400), ~ , FROM_UNIXTIME(partition_description)) AS range_interval FROM information_schema.partitions WHERE table_schema zabbix AND table_name IN (history_uint, trends) ORDER BY table_name, partition_description;这行 SQL 里我把partition_description的边界值减掉一天再格式化这样每行显示的是“该分区实际装的数据范围”而不是繁琐的秒数核查时一眼能看出哪个分区到期该删了。partition_description是边界值减一天是分区当天的 0 点对照分区名一目了然。第二步验证分区裁剪是否生效用EXPLAIN FORMATJSON看一条典型历史查询EXPLAIN FORMATJSON SELECT COUNT(*) FROM history_uint WHERE clock BETWEEN UNIX_TIMESTAMP(2025-05-01 00:00:00) AND UNIX_TIMESTAMP(2025-05-02 00:00:00)\G查看输出 JSON 中的partitions字段如果里面只有p20250501这一项说明查询只扫了一个分区裁剪生效如果显示所有分区名说明查询条件写得不匹配分区做了也白做。MySQL 8.0 里EXPLAIN不再单独显示 partitions 列用FORMATJSON最直观5.7 时代用EXPLAIN PARTITIONS SELECT ...的老套路就别拿着用了。第三步实测耗时。对同一张表跑一次全表扫描范围查询再跑一次按天的范围查询肉眼可见地从秒级降到毫秒级。最后再验证清理链路手动往history_uint插入一条两周前的数据跑一遍维护脚本确认数据没了data_free没有异常增长。这一套做完分区优化才算真正闭环。我最早一次做 Zabbix 7.0 分区时只建了未来三天的分区结果五一假期过后分区边界不够用凌晨告警刷屏那次的教训是“分区脚本的提前量永远要比节假日天数多”。后来我把分区脚本、定时校验、磁盘空间检查串成了一条独立于 Zabbix server 的维护流程才真正敢把这套平台交付出去。希望你这次部署不用走我那段弯路希望帮到你。本文还有配套的精品资源点击获取