运维与监控

-- 当前正在执行的查询（最常用！排查"谁在拖慢集群"）
SELECT query_id, user, elapsed, read_rows, memory_usage, query
FROM system.processes
ORDER BY elapsed DESC
LIMIT 10;
 
-- 杀掉某个跑飞的查询
KILL QUERY WHERE query_id = 'xxx';

-- 单查询内存上限（默认 0 = 用 max_server_memory_usage 的份额）
SET max_memory_usage = 10000000000;          -- 10 GB
 
-- 超过后是否落盘做"外部聚合/排序"（强烈建议开）
SET max_bytes_before_external_group_by = 8000000000;   -- 8 GB 后 Group By 落盘
SET max_bytes_before_external_sort = 8000000000;       -- 8 GB 后排序落盘
 
-- 整个服务端的内存上限（防止 OOM 把机器拖死）
-- 写在 users.xml 的 profiles 里，例如 max_server_memory_usage = 32 GB

GROUP BY 吃内存增长曲线：
  数据量小 → 全在内存，最快
  超过 max_bytes_before_external_group_by → 部分中间状态写磁盘（变慢但能跑）
  超过 max_memory_usage → 查询报错 "Memory limit exceeded"
  超过 max_server_memory_usage → 服务端自我保护，杀掉最耗内存的查询

-- 单节点同时执行的查询上限（默认 100）
SET max_concurrent_queries = 100;
 
-- 限制单用户并发，防止某个报表把集群打满
-- 在 users.xml 的 quotas 里配置

-- 这两条都会触发 mutation：重写包含匹配行的所有 part
ALTER TABLE events DELETE WHERE event_time < '2020-01-01';
ALTER TABLE events UPDATE duration_ms = duration_ms * 2 WHERE country = 'CN';

影响行数    实际重写量        耗时        对线上影响
  100 行    整个 part（可能 800 万行）   分钟级    重写期间该 part 不可读（短暂），merge 争抢 IO

-- 监控 mutation 进度，避免堆积
SELECT
    database, table, mutation_id,
    command, create_time, parts_to_do, is_done
FROM system.mutations
WHERE NOT is_done
ORDER BY create_time;

-- 冻结整张表（生成硬链接快照到 shadow/）
ALTER TABLE events FREEZE;
 
-- 只冻结某分区（更省）
ALTER TABLE events FREEZE PARTITION '202401';

# 全量备份到本地
clickhouse-backup create full_backup_20240101
 
# 恢复到指定表
clickhouse-backup restore full_backup_20240101 --table=default.events

查询慢
  ├─ 看 system.processes：是不是有别的查询在抢资源？
  ├─ 看 EXPLAIN indexes=1（16 章）：扫描了多少 granule？能否靠主键/跳数索引减少？
  ├─ 看 system.query_log.read_rows / memory_usage：是读太多行还是内存爆？
  ├─ 看 ProfileEvents：是否大量 DiskRead/CompressedRead 偏慢（IO 瓶颈）？
  └─ 看 system.merges：是不是 merge 太猛把 IO 占满了？
 
写入失败
  ├─ "Too many parts" → 写入太碎，加大批次 / 开 async_insert（10 章）
  ├─ "Memory limit exceeded" → 单批太大，拆小 / 调大限制
  └─ 副本写入卡住 → 查 system.replicas 的 queue_size 是否堆积，Keeper 是否存活
 
副本不一致
  ├─ system.replicas.absolute_delay 是否持续增长
  ├─ Keeper 连接是否断开
  └─ 必要时 SYSTEM RESTORE REPLICA（18 章）

-- 一键看"最慢的 10 个历史查询"
SELECT
    query,
    query_duration_ms,
    read_rows,
    memory_usage,
    normalized_query_hash
FROM system.query_log
WHERE type = 'QueryFinish'
ORDER BY query_duration_ms DESC
LIMIT 10;