用途：从 system.query_log、system.part_log、system.query_views_log、system.kafka_consumers、system.processes 与 system.text_log 出发，回答“插入为什么慢、失败或创建的 part 过多”。若连接模式、集群与时间窗口尚未确定，先运行 altinity-expert-clickhouse-connection。
主要能力：checks.sql 含 14 项检查，覆盖 Kafka 消费者健康与调度容量、正在运行与近期插入活动、每表 part 创建速率、插入与合并平衡、慢插入、插入上的物化视图开销、失败插入、批大小分布、Kafka 引擎摄入、日志中的 Kafka 消息、Buffer 表刷新模式与当前插入相关设置。其中 2 项需要 system.part_log，1 项需要 system.query_views_log，1 项需要 system.text_log。
使用方式：从技能目录读取每个包文件；逐条执行语句，不要整文件运行，语句以 ; 结束并以 -- @check <id> <title> 开头，结果保留 id。遵守 -- @requires：表缺失、需要 keeper 而服务器无 Keeper/ZooKeeper、或版本条件不满足时跳过，并列出跳过的 id 与原因。集群宏存在时保留 {cluster}，否则套用连接技能的重写规则；其他 {placeholder} 需先替换为真实值或跳过。出错时记录 check id 与错误首行后继续；仅对 UNKNOWN_IDENTIFIER 运行 DESCRIBE TABLE system.<table> 并去掉缺失列。severity 列即该行结论，照抄不要重新评级。
已知 query_id 的慢插入可用深层语句按物化视图拆分耗时：SELECT view_name, view_duration_ms, read_rows, written_rows, status, exception FROM system.query_views_log WHERE query_id = '{query_id}' ORDER BY view_duration_ms DESC;
解释规则：平均每次插入 written_rows 低于 1000 属微批，建议每 INSERT 批 1 万至 100 万行，或客户端无法批处理时启用 async_insert。ingestion-10 返回 batch_status 而非 severity。同一窗口内 NewPart 多而 MergeParts 少说明合并跟不上，问题在合并侧。query_views_log 显示视图耗时主导插入耗时时，修的是物化视图查询。Buffer 表自带刷新延迟，行仅在刷新后可见。part_log 禁用时需明确说明 part 创建速率与插入/合并平衡未知。失败插入中的 TOO_MANY_PARTS 是合并积压症状；插入上的 MEMORY_LIMIT_EXCEEDED 通常源自物化视图或超大单批。Kafka 检查在此仅作摘要，poll/commit 年龄上升或异常数组非空应转 Kafka 技能。
报告格式：头部含连接模式、集群或“单节点”、ClickHouse 版本、时间窗口；发现表含 check、severity、object、evidence、recommendation，Critical 优先；OK 检查一行列出无问题行的 id；跳过与失败检查须列 id 与原因或首行错误，不可省略；最后给出后续技能与即时动作。后续可转 Kafka、合并、报表、内存、schema、存储、复制等技能。