altinity-expert-clickhouse-storage

存储与磁盘使用分析

通过 system.disks、system.parts、system.columns、system.detached_parts、system.storage_policies、system.asynchronous_metrics、system.query_log 和 system.part_log，回答“磁盘空间都用到哪里了、数据压缩得好吗、磁盘能跟上吗？”如果尚未确定连接模式、集群和时间范围，请先运行 altinity-expert-clickhouse-connection。

查询包

• checks.sql — 19 项检查：磁盘剩余空间及严重程度、按数据库和表统计大小、按路径统计使用量、整体和逐表压缩比、压缩效果低于 2 倍的列、分区大小分布、小分区检测、Wide 与 Compact 分区的占比、磁盘 IO 指标、查询日志中的近期 IO、IO 负载最高的查询、系统日志的磁盘使用量、附带原因的分离分区、存储策略及使用这些策略的表、最近一小时的增长情况，以及作为磁盘速度代理指标的合并吞吐量。检查 storage-19 需要 system.part_log；如果该表不存在，请跳过。
• reference.md — 背景信息（设置、容量规划、反模式）；仅在需要解释建议时阅读。

如何运行查询包

1. 从此技能的目录读取每个包文件（技能加载器会打印目录路径）。
2. 每次运行一条语句，不要运行整个文件。语句以 ; 结尾，并以 -- @check <id> <title> 标题开头；请在结果中保留 ID。
3. 遵循 -- @requires：当指定的表缺失、要求 keeper 但服务器没有 Keeper/ZooKeeper，或版本条件不满足时，跳过该语句。列出跳过的 ID 和原因。
4. 如果存在集群宏，请按原样保留 {cluster}；否则应用连接技能的改写规则。其他任何 {placeholder} 都是模板变量：先替换为实际值，否则跳过该语句。
5. 发生错误时，记录检查 ID 和错误的第一行，然后继续。仅当错误为 UNKNOWN_IDENTIFIER 时，运行 DESCRIBE TABLE system.<table> 并删除缺失的列。
6. severity 列是该行的判定结果。照抄，不要重新评级。

解读规则

• storage-01 按已用空间占比评估剩余空间：已用空间超过 80% 为 Moderate，超过 85% 为 Major，超过 90% 为 Critical。将 Major 视为需要当天处理的问题。MergeTree 需要的剩余空间至少要与它将执行的最大合并所需空间一样大，因此磁盘在已用空间达到 90% 时，早在停止接受插入之前就会停止合并。
• 压缩比低于 2（storage-06、storage-07）意味着列类型或编解码器不合适，而不是数据无法压缩。添加显式编解码器：通用数据用 ZSTD，顺序整数用 Delta, ZSTD，时间戳用 DoubleDelta, ZSTD，重复字符串用 LowCardinality(String)。压缩比在 2 到 5 之间属于正常；高于 5 则表现良好。
• storage-09 仅返回超过一半的数据部件小于 10 MB 且数据部件数量超过 10 个的表。这要么是合并积压，要么是微批量插入，本身并不是存储问题。
• storage-10 中的 Wide 与 Compact：小于 min_bytes_for_wide_part（默认 10 MiB）的数据部件以 Compact 格式存储，所有列共用一个文件。大量微小的 Wide 数据部件意味着阈值被调低了，因此每个数据部件现在都要为每列占用一对文件。大型表如果全部以 Compact 格式存储，则意味着阈值被调高了，按列读取失去了粒度。
• storage-15 中的分离数据部件：以 broken、unexpected、noquorum 或 ignored 开头的原因指向数据损坏、操作失败或复制问题，移除前需要调查。clone 和 covered-by-broken 是残留数据，在需要磁盘空间时可以安全删除。
• storage-18 列出过去一小时内增长的内容。将其与 storage-03 对比：总体较小但位列此清单前列的表，就是将填满磁盘的表。
• storage-19 报告以字节每秒为单位的合并吞吐量。同一磁盘上的某个表持续吞吐量远低于其他表，表明设备速度较慢或已饱和；对象存储磁盘确实较慢，只应彼此比较。
• storage-14 中的大型系统日志表属于保留策略问题，而不是容量问题。不要建议为它们增加磁盘。

深入分析语句

查询单个表中每列的压缩后大小和编解码器，以确定要更改哪些编解码器：

SELECT name AS column, type, compression_codec, formatReadableSize(sum(data_compressed_bytes)) AS compressed, formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed, round(sum(data_uncompressed_bytes) / nullIf(sum(data_compressed_bytes), 0), 2) AS ratio FROM system.columns WHERE database = '{database}' AND table = '{table}' GROUP BY column, type, compression_codec ORDER BY sum(data_compressed_bytes) DESC;

查询单个表中每个分区的大小，以决定要删除或迁移哪些分区：

SELECT partition, count() AS parts, sum(rows) AS rows, formatReadableSize(sum(bytes_on_disk)) AS size, min(min_date) AS from_date, max(max_date) AS to_date FROM system.parts WHERE active AND database = '{database}' AND table = '{table}' GROUP BY partition ORDER BY partition;

报告格式

1. 标题：连接模式、集群或“单节点”、ClickHouse 版本、时间范围。
2. 发现：包含 check、severity、object、evidence、recommendation 列的表格；每项发现一行，按 Critical 优先排列。证据引用结果行中的数值。
3. 正常检查：用一行列出未返回问题行的检查 ID。
4. 跳过和失败的检查：列出 ID 和原因或首条错误信息。此部分不得省略。
5. 后续步骤：要加载的技能和需要立即采取的行动。

后续技能

• 压缩效果差、列类型错误或分区方式导致微小数据部件 → 加载技能 altinity-expert-clickhouse-schema
• 大量小数据部件、合并积压或合并吞吐量低 → 加载技能 altinity-expert-clickhouse-merges
• 写入 IO 过高或微批量插入 → 加载技能 altinity-expert-clickhouse-ingestion
• 系统日志表是最大的对象之一 → 加载技能 altinity-expert-clickhouse-logs
• 分离数据部件的原因为 broken 或 noquorum → 加载技能 altinity-expert-clickhouse-replication
• 随时间变化的数据部件创建、合并和移除速率 → 加载技能 altinity-expert-clickhouse-part-log
• 同一主机上的缓存或主键争用 RAM → 加载技能 altinity-expert-clickhouse-memory