ClickHouse 生产性能调优实战：写入、查询、内存与集群优化

四步框架：
① 量化现状：基线指标（写入吞吐、查询延迟、内存、CPU）
② 定位瓶颈：慢在哪一层（写入/查询/内存/磁盘/网络）
③ 对症优化：按瓶颈类型选优化手段
④ 验证闭环：优化后复测，确认收益再上线

瓶颈分层：
□ 写入慢 → 批量/格式/并发（第 2 节）
□ 查询慢 → 索引/分区/裁剪（第 3 节）
□ 内存爆 → 配额/并发/聚合内存（第 4 节）
□ 存储膨胀 → 压缩/编码/引擎（第 6 节）
□ 集群不均 → 分片/副本/负载（第 7 节）

先建基线：
□ 写入：rows/s、MB/s、插入延迟
□ 查询：P50/P95/P99 延迟、吞吐
□ 资源：CPU、内存、磁盘 IO、网络
→ 没有基线，优化无法证明「快了多少」

定位口诀：
写入慢看「批量 + 格式」
查询慢看「索引 + 裁剪」
内存爆看「聚合 + 并发」
存储涨看「压缩 + 编码」
集群偏看「分片 + 副本」
→ 对症下药，别盲调参数

写入三要素：
□ 批量：一次插入的「行数 × 大小」
  → 大 batch 明显优于小 batch（每次插入有开销）
  → 建议：几千~几万行/批，或用异步插入
□ 并发：同时写入的连接数
  → 并发太高 → 分区/part 太多 → merge 压力大
  → 建议：合理并发（个位数~十位数），别无脑高
□ 格式：数据格式与解析开销
  → Native/Parquet（紧凑）优于 JSON 逐行解析
  → 类型对齐（避免 String 转大数）

写入的隐藏成本：
□ part 数量：频繁小插入 → 大量小 part → merge 跟不上
  → 用异步插入 / 合理 batch 控制 part 增速
□ 唯一键/去重：Replacing/去重表有额外开销
□ 物化视图：每插入都要增量更新 → 别加太多视图

异步插入（Async Insert）：
□ 客户端攒批后台刷 → 批量收益 + 低延迟体验
□ 注意：异步有「提交延迟」，实时性敏感要权衡

-- 推荐写入模式（批量 + 缓冲）
INSERT INTO events SELECT * FROM input(...) -- 大 batch
-- 或启用异步插入
SET async_insert = 1;
INSERT INTO events ...;  -- 后台攒批写入

查询读数据的路径：
表 → 分区裁剪（跳过无关分区）→ 索引裁剪（跳过数据块）→ 读目标数据

分区裁剪（PARTITION BY）：
□ 查询 WHERE 含分区键 → 只扫相关分区
□ 设计：按「高频过滤列」分区（如按天/月）
□ 别过度：分区太多 → 大量小文件 → 查询/合并都差

索引（ORDER BY 主键）：
□ ClickHouse 主键 = 排序键 + 稀疏索引
□ 查询 WHERE 含主键前缀 → 快速跳过数据块
□ 设计：主键按「查询过滤顺序」排（高基数在前）

数据裁剪（Skip Index / 投影）：
□ 二级跳数索引：跳过大范围不匹配的数据
□ 投影（Projection）：物化冗余列/聚合加速
□ 分区内粗粒度裁剪减少扫描量

查询写法配合：
□ WHERE 尽量用主键列（前缀匹配）
□ 避免全表无分区裁剪的扫描
□ 聚合/过滤下推：物化视图或投影兜底

-- 设计范例：分区 + 主键匹配查询模式
ORDER BY (event_time, user_id)      -- 时间范围 + 用户过滤
PARTITION BY toYYYYMM(event_time)   -- 按月分区
-- 查询 WHERE event_time >= ... AND user_id = ... → 全走裁剪

内存消耗来源：
□ 查询执行：聚合（GROUP BY）/排序/join 的内存
□ 并发查询：同时运行的查询 × 各自内存
□ 写入缓冲：大 batch / 异步插入缓冲
□ 后台任务：merge、物化视图增量

内存控制机制：
□ max_memory_usage：单查询内存上限
□ max_concurrent_queries：并发查询上限
□ 内存配额（user quota）：按用户/角色限制
□ 内存超限行为：OOM / 磁盘溢出（spill to disk）

内存优化的手段：
□ 聚合下推：物化视图预聚合 → 查询内存大减
□ 分区裁剪：少扫数据 = 少占内存
□ 低基数优化：Dictionary/低基数列省内存
□ 限制并发：并发太高 → 排队，别同时爆内存
□ spill to disk：大数据聚合允许落盘（慢但稳）

超时与资源保护：
□ 查询超时：max_execution_time → 防长查询拖死服务
□ 只读保护：只读用户/查询限制
□ 资源隔离：重查询单独用户/单独节点

典型症状：
□ 内存不足/查询被杀 → 查 max_memory_usage 与并发
□ 服务卡顿 → 看是否被大查询占满内存

内存调优流程：
1. 看监控：内存峰值、被杀的查询
2. 查大查询：system.query_log 内存占用 Top
3. 对症：限并发 / 限内存 / 聚合下推 / spill

为什么需要预聚合：
□ 明细表每次查询全量聚合 → 慢、耗内存
□ 高频指标（看板）不该每次都重算
□ 物化视图：插入时增量更新 → 查询命中结果

三种预聚合形态：
□ 物化视图（MATERIALIZED VIEW）：源表插入 → 增量写目标表
□ 聚合表引擎：AggregatingMergeTree（sumState/countState）
  → SummingMergeTree（同键求和）
□ 投影（Projection）：表内冗余聚合列（自动用）

设计原则：
□ 预聚合的粒度先定（分钟/小时/天）
□ 聚合键 = 查询的 GROUP BY 维度
□ 指标 = 查询需要的聚合（sum/count/uniq/quantile）

收益与代价：
□ 查询：秒级（命中预聚合）
□ 代价：写放大（每插入都更新）+ 存储增加
□ 权衡：只预聚合「高频 + 固定」的查询

组合用法：
□ 多级聚合：分钟 → 小时 → 天（逐级物化）
□ 明细 + 聚合并存：明细可下钻，聚合跑指标

-- 小时级预聚合物化视图（示意）
CREATE MATERIALIZED VIEW mv_hour
ENGINE = SummingMergeTree ORDER BY (day, hour)
AS SELECT toStartOfHour(ts) AS hour, user_id, sum(amount) AS amt
FROM events GROUP BY hour, user_id;
-- 查询命中预聚合 → 秒级
SELECT hour, sum(amt) FROM mv_hour GROUP BY hour;

表引擎选择（见表引擎篇）：
□ MergeTree：默认，明细 + 范围查询
□ Aggregating/Summing：预聚合场景
□ Replacing：去重场景（防重复）
□ Distributed：分布式写入入口

压缩与编码：
□ 默认压缩（LZ4）：快但压缩比一般
□ ZSTD：压缩比高（省磁盘，代价是解压 CPU）
□ 列编码：适合低基数列（字典编码等）
→ 按「查询频率 + 磁盘成本」选：热查询用 LZ4，冷归档用 ZSTD

存储与 IO 的权衡：
□ 高压缩 → 省磁盘 + 省 IO（读更少字节）→ 但解压 CPU 增
□ 稀疏/编码列 → 查询裁剪更细
□ 分区粒度：太碎 → 小文件多、IO 碎片；太粗 → 裁剪失效

调优方向：
□ 冷热分层（见 S3 篇）：热本地 + 冷 S3
□ 大表拆分：按时间分区 + 归档老分区
□ 主键列数：主键列越多 → 索引越胖、插入开销大
  → 主键保持「够用」（覆盖查询前缀即可）

存储调优决策：
磁盘贵 / 冷数据多 → ZSTD + S3 冷层
查询热 / 要快 → LZ4 + 热本地
主键列 → 只留查询必需的（勿堆砌）
分区 → 匹配查询裁剪粒度（勿碎勿粗）

分布式集群要素：
□ 分片（Shard）：数据水平拆分 → 并行计算 + 容量扩展
□ 副本（Replica）：数据冗余 → 高可用 + 读负载分担
□ 分布式表（Distributed）：写入/查询的统一入口

分片设计：
□ 分片键：高基数 + 均匀（如 user_id）
□ 分片数：匹配节点数、数据量
□ 倾斜：分片键不均匀 → 热点分片（写入/查询都偏）

副本设计：
□ 副本数：至少 2（高可用），读可分担
□ 副本一致性：复制靠后台（MergeTree 复制）
□ 读放大：查询走分布式表 → 跨节点聚合

负载与瓶颈：
□ 写入：分布式表 → 分片均衡写入（避免单点）
□ 查询：分布式查询 → 分片并行 + 副本分担
□ 热点：分片不均 / 单副本扛全部读

扩展路径：
□ 先加副本（读扩展）→ 再加分片（容量/写扩展）
□ 冷数据不占热节点（S3 冷层）
□ 监控分片差异：数据量、part 数、查询分布

集群决策：
读瓶颈 → 加副本（分担读）
写瓶颈 → 加分片（拆写入）
容量不够 → 加分片 + S3 冷层
倾斜 → 换分片键 / 二次分片

流程六步：
① 抓到慢查询：system.query_log（耗时、内存、扫描量）
② 看扫描量：read_rows / read_bytes
  → 扫描量大 → 裁剪没生效（分区/索引/WHERE）
③ 看耗时分布：主要在「扫描」还是「聚合/排序」
  → 扫描久 → 裁剪问题；聚合久 → 预聚合问题
④ 看内存：聚合内存大 → 预聚合/限内存
⑤ 看并发影响：是不是并发高互相拖累
⑥ 对症优化 + 复测

常见案例：
□ 全表扫描：WHERE 列不在分区/主键 → 加分区/改主键
□ 聚合慢：大 GROUP BY 每次重算 → 物化视图预聚合
□ 内存爆：并发大聚合 → 限并发 + spill + 下推
□ 写入慢：小 batch 频繁插 → 批量/异步插入
□ part 爆炸：插入太碎 → merge 跟不上 → 控插入频率

-- 慢查询定位（system.query_log）
SELECT query, read_rows, read_bytes, memory_usage, query_duration_ms
FROM system.query_log
WHERE query_duration_ms > 1000
ORDER BY read_bytes DESC LIMIT 10;

定位口诀：
scan 大 + 耗时 → 裁剪问题（分区/索引/WHERE 列）
scan 小 + 聚合慢 → 预聚合问题（物化视图）
内存爆 → 并发/聚合内存
→ 每类问题都有明确解法，别乱调参

监控指标分层：
□ 系统层：CPU、内存、磁盘 IO、网络（节点健康）
□ 查询层：P50/P95/P99 延迟、并发、慢查询数
□ 写入层：写入吞吐、part 数、merge 队列
□ 数据层：表大小、分区分布、倾斜度

工具：
□ system.query_log（慢查询、内存、扫描量）
□ system.metrics / system.events（运行指标）
□ system.parts（part 数、大小、层级）
□ 外部：Prometheus + Grafana（长期趋势）

持续优化节奏：
□ 每周：慢查询 Review（前 N 条，归因 + 修复）
□ 每月：容量与趋势（数据增长 → 分层/分区调整）
□ 每次变更：基线对比（调参前 vs 后）

健康信号：
□ part 数稳定（不暴涨）
□ merge 队列不积压
□ P95 平稳、无突刺
□ 分片数据均衡

常见退化：
□ 数据涨了分区没动 → 扫描变慢
□ 查询模式变了预聚合没跟上 → 慢查询回升
□ 并发上去了内存配额没调 → 偶发 OOM

持续优化循环：
监控 → 发现异常 → 归因定位 → 对症优化 → 复测 → 回归监控
→ 慢查询 Review 是最低成本的高杠杆动作