system.merges表用于监控clickhouse后台合并任务，关键字段包括database/table、elapsed、progress、size_bytes_compressed、total_size_bytes_compressed和is_mutation；通过select查询可识别耗时>60秒或progress停滞的异常任务，并需结合system.parts、system.disks和system.mutations交叉诊断。
clickhouse 的 system.merges 表用于实时监控正在执行的后台合并（Merge）任务，是排查写入延迟、查询卡顿或磁盘空间异常增长的关键入口。
理解 system.merges 的核心字段
该表每行代表一个正在运行的合并任务，重点关注以下字段：
- database / table：所属数据库和表名，便于定位问题来源
- elapsed：当前合并已耗时（秒），持续增长且远超正常值（如 >300 秒）可能表明 I/O 瓶颈或数据倾斜
- progress：合并进度（0.0–1.0），长期卡在某个值（如 0.999）通常意味着某 part 写入失败或磁盘满
- size_bytes_compressed / total_size_bytes_compressed：已处理与总需处理压缩字节数，可估算剩余工作量
- is_mutation：是否为 ALTER UPDATE/delete 引发的 mutation 合并，这类任务优先级低、耗时更长
快速识别异常合并任务
执行以下查询定位潜在问题：
SELECT database, table, elapsed, round(progress, 3) AS prog, is_mutation, size_bytes_compressed, total_size_bytes_compressed FROM system.merges WHERE elapsed > 60 OR progress
重点关注：
- elapsed > 300 秒且 progress 停滞 → 检查磁盘 I/O 利用率和可用空间
- 同一张表出现多个长时间运行的 merge → 可能因频繁小批量写入导致 part 过多，触发“合并风暴”
- is_mutation = 1 且长时间未完成 → 查看
system.mutations中对应 mutation 状态，确认是否被阻塞
关联诊断常用组合查询
单看 system.merges 不够，需结合其他系统表交叉验证：
- 查表级 part 数量：
select database, table, count() AS parts_cnt FROM system.parts WHERE active GROUP BY database, table ORDER BY parts_cnt DESC LIMIT 5;（parts > 500 易引发合并压力） - 查磁盘空间压力：
SELECT disk_name, formatReadableSize(free_space) AS free, formatReadableSize(total_space) AS total FROM system.disks; - 查 mutation 卡住原因：
SELECT database, table, mutation_id, command, create_time, latest_failed_part, latest_fail_time, latest_fail_reason FROM system.mutations WHERE is_done = 0;
临时缓解与长期优化建议
发现异常合并时可酌情操作：
- 对非关键表，用
KILL MUTATION WHERE database='db' AND table='t';终止卡死的 mutation（注意：已写入的数据不可逆） - 调大合并线程数（谨慎）：
SET background_pool_size = 32;（默认 16，需确保 CPU 和 I/O 资源充足） - 长期建议：调整
index_granularity和写入批次大小，减少小 part 生成；启用ttl自动清理旧数据；定期OPTIMIZE TABLE ... FINAL（仅限低峰期）