ClickHouse执行ALTER DELETE时报错：未找到_block_number列

问题分析 #

该报错是因为目标分区（202203）内的部分数据块缺少ClickHouse内部元数据列_block_number，导致mutation无法正常执行。更早日期的删除语句正常，说明仅该分区存在数据块结构异常，大概率是历史导入操作或版本兼容问题导致。

解决方案 #

1. 定位异常数据块 #

先确认分区内哪些数据块存在问题：

SELECT name, columns, active 
FROM system.parts 
WHERE table = 'event_performances' 
  AND partition_id = '202203';

对比正常分区的数据块columns字段，找出未包含_block_number的异常块。

2. 修复异常数据块 #

方法一：合并分区数据块（优先尝试）

执行分区合并操作，强制重新生成包含完整元数据的新数据块：

OPTIMIZE TABLE event_performances PARTITION '202203' FINAL;

注意：大分区执行此操作会占用较多资源，建议在业务低峰期运行。

方法二：导出重导数据（合并无效时使用）

如果合并操作无法修复，采用导出-删除-重导的方式：

1. 导出分区数据：

SELECT * INTO OUTFILE '/tmp/202203_event_data.csv' 
FROM event_performances 
WHERE toYYYYMM(event_timestamp) = 202203;

2. 删除异常分区：

ALTER TABLE event_performances DROP PARTITION '202203';

3. 重新导入数据：

INSERT INTO event_performances FORMAT CSV 
FROM INFILE '/tmp/202203_event_data.csv';

注意：操作前需确保Buffer表已将数据flush到主表，避免数据丢失。

3. 重新执行删除语句 #

修复完成后，再次运行原删除语句：

ALTER TABLE event_performances
 DELETE
 WHERE is_deleted = 1 
 AND event_timestamp = '2022-03-03 05:00:00'
 SETTINGS mutations_sync=2, alter_sync=2;

4. 后续预防 #

• 检查历史数据导入流程，确保导入工具与当前ClickHouse版本兼容，避免元数据缺失。
• 定期对旧分区执行OPTIMIZE操作，保持数据块结构一致性。
• 用以下语句监控mutation执行状态，及时处理失败任务：

SELECT * FROM system.mutations WHERE table = 'event_performances';

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