刚好处理过Zabbix分区表的这类问题，我来给你一步步拆解：

一、为啥日期变更后写不进数据？ #

核心原因基本逃不出这几个：

• 没提前建对应新日期的分区：RANGE分区是严格匹配范围的，要是新日期的clock时间戳不在任何已定义的分区里，数据库直接就会报错拒绝插入，Zabbix自然写失败。
• 分区边界值算错了：比如你把分区上限设成了当天23:59:59的时间戳，但Zabbix写入的clock是第二天的时间，或者你误把毫秒当成秒来计算边界，导致范围完全不对。
• Zabbix和数据库时间不同步：如果Zabbix服务器的系统时间和数据库差得远，写入的clock值就会偏离预期的分区范围。

二、怎么查看所有分区？ #

在MySQL/MariaDB里执行这两个命令就能搞清楚所有分区的情况：

-- 查看分区基本信息：名称、分区方式、对应字段、边界值、数据行数
SELECT PARTITION_NAME, PARTITION_METHOD, PARTITION_EXPRESSION, PARTITION_DESCRIPTION, TABLE_ROWS 
FROM INFORMATION_SCHEMA.PARTITIONS 
WHERE TABLE_SCHEMA = 'zabbix' AND TABLE_NAME = 'history';

-- 查看分区完整定义，包括每个分区的具体边界规则
SHOW CREATE TABLE zabbix.history;

执行后就能确认是不是缺了新日期的分区，或者边界值有没有设置错误。

三、怎么让数据顺利写入对应分区？ #

分紧急修复和长期方案两步来：

1. 先紧急补上缺失的分区 #

如果确实是缺了新日期的分区，手动创建一个就行。比如今天是2024-05-20，明天0点的UNIX时间戳是1716240000，那创建明天的分区语句如下：

ALTER TABLE zabbix.history 
ADD PARTITION (
    PARTITION p20052024 
    VALUES LESS THAN (1716240000)
);

注意：VALUES LESS THAN后面的数值是下一个分区的起始时间戳，当前分区包含的是「上一个分区上限，当前分区上限）的时间戳范围，别搞反了。

2. 长期解决：自动创建分区 #

总手动建分区太麻烦，写个shell脚本配合crontab每天自动创建第二天的分区就搞定了。示例脚本如下：

#!/bin/bash
# 获取明天0点的UNIX时间戳
NEXT_DAY_TIMESTAMP=$(date -d "tomorrow 00:00:00" +%s)
# 生成分区名称，格式比如p20052024
PARTITION_NAME="p$(date -d "tomorrow" +%d%m%Y)"

# 连接数据库执行创建命令（替换成你的数据库账号密码）
mysql -u zabbix_user -p'your_zabbix_password' zabbix << EOF
ALTER TABLE history ADD PARTITION (
    PARTITION $PARTITION_NAME
    VALUES LESS THAN ($NEXT_DAY_TIMESTAMP)
);
EOF

把这个脚本保存成zabbix_create_partition.sh，加执行权限chmod +x zabbix_create_partition.sh，然后加入crontab，每天凌晨1点执行：

0 1 * * * /path/to/zabbix_create_partition.sh

这样就能提前创建好第二天的分区，再也不会出现写不进去的问题。

额外要注意的点 #

• 确认分区字段是clock：执行SHOW CREATE TABLE zabbix.history时，要保证PARTITION BY RANGE后面是(clock)——因为clock本身就是UNIX时间戳，不需要再套UNIX_TIMESTAMP()函数，不然分区匹配会出错。
• 时间同步要做好：Zabbix服务器和数据库服务器都得开NTP同步时间，避免时间差导致的分区不匹配。

内容的提问来源于stack exchange，提问作者1.01011E+12