MySQL 8.1按月分区后CURRENT_TIMESTAMP默认值失效问题咨询

这是正常现象吗？ #

这不属于MySQL的正常预期行为，但属于分区表的已知约束。问题根源在于你的分区键使用了表达式to_days(dlvCreated)，且dlvCreated同时是联合主键的一部分。插入数据时，MySQL需要先计算分区键的值来确定数据存放的分区，但此时dlvCreated的默认值还未生成，导致MySQL无法完成分区判断，因此不会自动触发CURRENT_TIMESTAMP默认值，反而要求你显式指定dlvCreated的值，最终表现为默认值“失效”。

替代方案 #

1. 直接使用字段作为分区键（推荐） #

MySQL 8.0+支持直接用datetime类型作为RANGE分区的列，无需通过to_days转换。修改分区定义为：

ALTER TABLE datalogvalues1
PARTITION BY RANGE COLUMNS(dlvCreated) (
  PARTITION from202211 VALUES LESS THAN ('2022-12-01'),
  PARTITION from202212 VALUES LESS THAN ('2023-01-01'),
  PARTITION from202301 VALUES LESS THAN ('2023-02-01'),
  PARTITION from202302 VALUES LESS THAN ('2023-03-01'),
  PARTITION from202303 VALUES LESS THAN ('2023-04-01'),
  PARTITION from202304 VALUES LESS THAN ('2023-05-01'),
  PARTITION from202305 VALUES LESS THAN ('2023-06-01'),
  PARTITION from202306 VALUES LESS THAN ('2023-07-01'),
  PARTITION from202307 VALUES LESS THAN ('2023-08-01'),
  PARTITION from202308 VALUES LESS THAN ('2023-09-01'),
  PARTITION from202309 VALUES LESS THAN ('2023-10-01'),
  PARTITION from202310 VALUES LESS THAN ('2023-11-01'),
  PARTITION from202311 VALUES LESS THAN ('2023-12-01'),
  PARTITION future VALUES LESS THAN MAXVALUE
);

这种方式下，MySQL会先为dlvCreated生成默认值，再根据值确定分区，默认值逻辑可以正常生效。

2. 使用触发器实现默认值逻辑 #

如果无法修改分区方式，可以通过触发器替代默认值的自动赋值：

插入触发器

DELIMITER //
CREATE TRIGGER trg_datalogvalues1_before_insert
BEFORE INSERT ON datalogvalues1
FOR EACH ROW
BEGIN
  -- 若未指定dlvCreated，自动赋值当前时间戳
  SET NEW.dlvCreated = COALESCE(NEW.dlvCreated, CURRENT_TIMESTAMP);
  -- 若未指定dlvModfied，自动赋值当前时间戳
  SET NEW.dlvModfied = COALESCE(NEW.dlvModfied, CURRENT_TIMESTAMP);
END //
DELIMITER ;

更新触发器（保留更新时自动修改时间戳）

DELIMITER //
CREATE TRIGGER trg_datalogvalues1_before_update
BEFORE UPDATE ON datalogvalues1
FOR EACH ROW
BEGIN
  SET NEW.dlvModfied = CURRENT_TIMESTAMP;
END //
DELIMITER ;

触发器会在插入/更新数据时强制处理时间戳赋值，不受分区逻辑影响。

3. 调整主键结构（不推荐） #

如果业务允许，可以将dlvCreated从联合主键中移除，仅保留dlvID作为主键。这样MySQL插入时可以先生成dlvCreated的默认值，再确定分区。但此方案会改变表的约束结构，需评估对业务的影响后再操作。

内容的提问来源于stack exchange，提问作者John King