企业官网建设流程全解析

大概半年前，我手里接了一个统计报表需求：几千万行的用户行为日志，要按照维度标签做实时聚合，MySQL 直接卡死，查一次要等小半分钟还不一定出得来。当时第一反应就是上 ClickHouse，毕竟列式存储、向量化执行这套东西在 OLAP 场景就是碾压级的存在。

不过真正动手时才发现，ClickHouse 官方部署虽然也不复杂，但要自己处理依赖、目录权限、系统参数，还是挺折腾的。后来切到 Docker 部署，一条命令把服务拉起来，配置、数据目录、日志全部挂载到宿主机，升级回滚都干净利落。这篇文章就把我这半年的实操经验完整写下来，从最基础的 Docker 部署到配置调优、备份迁移、常见故障排查，适合后端开发、数据分析师、运维工程师参考。看完你也能在十几分钟内把一套 ClickHouse Server 跑起来，并且知道后面怎么维护它。

1. 项目背景与需求定位

1.1 什么样的场景需要 ClickHouse

先想清楚一个问题：你为什么要用 ClickHouse？它不是用来替代 MySQL 或者 SQL Server 做在线事务处理的，ClickHouse 的定位非常明确——面向分析型负载（OLAP）。

我见过不少团队把用户表、订单表直接往 ClickHouse 里塞，然后期望它能像 MySQL 一样支持高频单行更新，结果用起来非常别扭。ClickHouse 真正擅长的是“海量数据的聚合分析”。举个例子，你有十亿条访问日志，想按小时、按渠道统计 PV/UV，这种查询在传统关系型数据库里往往需要扫描大量行，即使加了索引也容易卡死。ClickHouse 因为采用列式存储，查询时只读取涉及的列，再加上向量化执行引擎，同样的集群配置下经常是几十倍甚至上百倍的速度提升。

适合上 ClickHouse 的典型场景包括：用户行为分析、日志分析、监控指标存储、AB 实验数据统计、金融行情历史数据分析等。核心特征有两个：一是数据量大，单表轻松上亿行；二是查询模式以宽表扫描、聚合、分组为主，而不是频繁的单行点查。

需要提醒的是，ClickHouse 对单行更新和删除的支持很弱，虽然新版本有轻量级删除和更新，但那是异步的、面向批量操作的，不适合事务型业务。如果你的核心诉求是订单写入和实时修改，那还是继续用 MySQL、PostgreSQL 或者 SQL Server 吧。这个定位想清楚，后面所有部署和表结构设计才不会有方向性错误。

1.2 为什么选择 Docker 来部署

ClickHouse 官方其实提供了通用二进制包、deb/rpm 包、源码编译这些安装方式。如果只装一台测试机，二进制包解压就能跑，也不复杂。但一旦你要在多台机器上部署、保证版本一致、快速回滚版本，Docker 的优势就非常明显了。

Docker 镜像把 ClickHouse 的二进制、默认配置、依赖库全部打包在一起，拉下来就能跑。你不用在一台新服务器上折腾“缺 libicu、缺 libltdl”这种环境依赖问题，也不用担心系统自带的 glibc 版本太低。尤其是 CentOS 7 这类老系统，自己编译 ClickHouse 能折腾掉你半天时间。

另外，Docker 容器默认就和宿主机隔离了文件系统，这意味着 ClickHouse 的数据目录、日志目录、配置文件都可以通过挂载卷映射到宿主机。升级的时候只需要拉一个新版本镜像、重新起一个容器，数据目录不动，配置不动，起不来就滚回旧镜像。相比直接替换二进制包，这种“环境整体替换、数据与配置分离”的方案，运维心智负担低很多。

我看过不少团队会用 Docker Compose 一次性编排 ClickHouse 和它的依赖服务，比如后续要上集群复制时搭配 ClickHouse Keeper 或 ZooKeeper，再比如和 Grafana、Vector 等数据管道接在一起。用 Docker 做这类编排，比手动去一个个启动进程要顺手得多。这篇文章后面演示的也是 Docker 和 Docker Compose 两种部署方式。

2. 部署前准备：环境、镜像与目录规划

2.1 Docker 环境准备

部署前先确认宿主机能正常跑 Docker。Linux 环境最简单，安装 Docker Engine 后启动守护进程就行。macOS 和 Windows 一般装 Docker Desktop，注意 Windows 要开启 WSL2 后端或者 Hyper-V，否则 Docker Desktop 会启动失败，报错信息五花八门，最常见的就是“Virtualization support not detected”。

我在 Windows 上遇到过这个报错，排查后发现是 BIOS 里的虚拟化选项没打开。处理方法：重启进 BIOS 设置，找到 Intel Virtualization Technology / AMD SVM，开启后保存退出；然后在 Windows 功能里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，重启后再重新安装或启动 Docker Desktop。如果系统版本比较老，很多坑都是出在 WSL 内核没更新上，执行一下wsl --update基本能解决。

内存方面，ClickHouse 本身对内存并不算特别敏感，但分析查询时如果数据集较大，内存不够会让查询退化为磁盘排序，速度就掉下来了。我自己实际使用的标准是：测试环境至少给容器 4GB 内存，生产环境 16GB 起步，当然这要结合你的数据量来定。如果宿主机内存紧张，至少保证 Docker Desktop 能分配到 4GB 以上。

2.2 镜像选型与版本策略

ClickHouse 官方镜像名是clickhouse/clickhouse-server，Docker Hub 上可以直接拉取。镜像 tag 有几种系列：latest、24.x、25.x这种具体版本号，还有head（开发版）和alpine（基于 Alpine Linux 的瘦身版）。

我的建议是生产环境不要追latest，也不要追head。ClickHouse 版本迭代非常快，有些新特性还不稳定，我就吃过亏：用latest部署，后来镜像更新了一个小版本，结果某个 SQL 方言行为变了，导致跑批任务结果不一致。现在我的做法是锁定大版本，比如25.3或者某个固定的25.3.1.1这种完整版本号，先在测试环境跑一段时间，确认稳定后再上生产。

Alpine 版本镜像更小，但 ClickHouse 对 glibc 有依赖，Alpine 用的是 musl libc，虽然官方做了适配，但是有一些底层行为差异，遇到疑难问题排查起来更费劲。如果你不是对镜像体积特别敏感，我建议直接用默认的 Debian 版本，少踩坑。

拉镜像的命令很简单：

docker pull clickhouse/clickhouse-server:25.3

如果服务器在国内，拉 Docker Hub 镜像可能很慢。解决办法是给 Docker 配置镜像加速器。注意现在很多公开加速器都失效了，比较稳妥的做法是找一个可用的镜像源写在/etc/docker/daemon.json里，然后重启 Docker。就算没有加速器，多试几次或者挑非高峰时段拉，一般也能拉下来。

2.3 容器数据目录规划

ClickHouse 容器里面有三个目录需要重点关注：

• /var/lib/clickhouse：数据目录，存放数据库、表、分区数据
• /var/log/clickhouse-server：日志目录，包含clickhouse-server.log和clickhouse-server.err.log
• /etc/clickhouse-server：配置文件目录，主要是config.xml和users.xml

部署时一定要把这三个目录通过 volume 挂载到宿主机，否则容器一删，数据全没了。这是一个血泪教训：有次我在测试环境图省事没挂数据目录，后来清理容器时把测试数据全部干掉了，白白浪费了一个下午重建。

挂载目录的宿主路径建议单独规划，比如统一放在/data/clickhouse/{data,logs,config}下。这样做的好处是：备份的时候只需要打包/data/clickhouse这一个父目录；升级的时候新容器挂载同一个数据目录，数据无缝衔接。

在 Windows 上用 Docker Desktop 挂载宿主机目录到容器，性能会比 Linux 原生差一些，但测试用完全没问题。生产环境建议还是用 Linux 宿主机部署，磁盘 IO 对 ClickHouse 查询性能影响挺大的，尤其是 MegeTree 这类表引擎在合并分区时要大量读写磁盘，IO 慢会拖累 merge 速度。

3. Docker 部署 ClickHouse Server 完整实操

3.1 一条命令跑起单节点

如果你只是想本地快速验证一下，先不关心配置，一条命令就能跑起来：

docker run -d \ --name clickhouse-server \ --ulimit nofile=262144:262144 \ -p 8123:8123 \ -p 9000:9000 \ clickhouse/clickhouse-server:25.3

解释一下这几个参数：

• --ulimit nofile=262144:262144：把文件描述符上限调到 262144。ClickHouse 官方文档明确要求这个值，因为分析型查询会打开大量文件，默认的 1024 很容易触发 “Too many open files” 报错。这是很多人部署完以后遇到莫名 IO 异常的头号原因。
• -p 8123:8123：HTTP 端口，REST API 和 ClickHouse 的 HTTP 接口都走这个端口，后续配合各类 BI 工具、数据可视化平台基本都是用它。
• -p 9000:9000：ClickHouse 原生 TCP 协议端口，clickhouse-client命令行工具和大多数编程语言 SDK 默认走这个端口。

除了上面两个，还有两个端口值得注意。9009是集群节点间数据复制用的，单机部署用不到；9440是原生协议 SSL 端口，安全要求高的时候才用。

跑起来后看下状态：

docker ps docker logs -f clickhouse-server

看到日志里出现Ready for connections就说明服务已经启动了。继续用客户端工具验证一下：

docker exec -it clickhouse-server clickhouse-client

进入客户端后执行SELECT version();，能返回版本号就说明一切正常。

3.2 用 docker-compose 做规范化部署

生产环境我不建议直接用上面的docker run，参数一多就容易漏，而且不方便团队其他人维护。用 Docker Compose 把配置固化到文件里是更好的做法。

我的推荐目录结构是这样的：

/opt/clickhouse/ ├── docker-compose.yml ├── config/ │ ├── config.d/ │ └── users.d/ ├── data/ └── logs/

docker-compose.yml内容如下：

version: "3.8" services: clickhouse: image: clickhouse/clickhouse-server:25.3 container_name: clickhouse-server restart: unless-stopped ulimits: nofile: soft: 262144 hard: 262144 ports: - "8123:8123" - "9000:9000" volumes: - ./data:/var/lib/clickhouse - ./logs:/var/log/clickhouse-server - ./config/config.d:/etc/clickhouse-server/config.d:ro - ./config/users.d:/etc/clickhouse-server/users.d:ro environment: - CLICKHOUSE_PASSWORD=your_strong_password

这里几个关键点：

restart: unless-stopped保证宿主机重启后容器自动拉起，对于服务器重启这种场景非常重要，不然每次机器重启都要手动 start 一次。

CLICKHOUSE_PASSWORD环境变量是官方镜像提供的一个快捷方式，设置后会自动创建一个default用户并配置密码。注意这只对默认用户生效。如果你需要创建多个用户或者配置更细粒度的权限，还是要通过挂载users.d下的 XML 文件来实现。

config.d和users.d这两个目录是 ClickHouse 提供的一个扩展机制：config.xml和users.xml是主配置，而config.d和users.d下的 XML 文件会在启动时被自动合并进去。它解决了“默认配置不动、新增配置独立放”的问题，升级镜像时不会因为配置文件格式变化而覆盖掉你的自定义配置。

准备好目录并写入上面的docker-compose.yml后，在/opt/clickhouse目录下执行：

docker compose up -d

等待几十秒后，执行docker compose ps看到状态是Up，就说明部署成功了。

3.3 验证服务与首次连接

服务跑起来后，有三个角度可以验证：

通过命令行客户端连：

docker exec -it clickhouse-server clickhouse-client --password

输入你设置的密码后，进入clickhouse-server的 SQL 命令行环境。执行：

SHOW DATABASES;

能看到default、system等默认库就 OK。

通过 HTTP 接口测试：

ClickHouse 的 HTTP 端口 8123 可以直接用curl请求，非常方便：

curl 'http://localhost:8123/?query=SELECT%201' --data-binary 'password: your_strong_password'

或者用-u方式传用户名密码：

curl -u default:your_strong_password 'http://localhost:8123/?query=SELECT+version()'

返回版本号就说明 HTTP 服务正常。

通过 DBeaver 等可视化工具连接：

社区常用的 DBeaver 支持 ClickHouse 驱动，连接参数填宿主机 IP、端口 8123、用户名default、密码，驱动会自动识别。另外像 Grafana 这类可视化平台，也有 ClickHouse 数据源插件，配置好 HTTP 地址后就能画监控面板。

我在这里提一个比较容易踩的点：clickhouse-client在容器内连接时，默认连接地址是localhost，如果你在宿主机上安装了clickhouse-client，连接时需要用-h 127.0.0.1，否则它默认走 9000 端口检查一遍发现连不上就直接报错了。要分清容器内客户端和宿主机客户端这两个场景。

4. 初始化数据表与性能验证

4.1 建库建表与基本写入

部署只是第一步，真正跑起来还是要建表。ClickHouse 的表引擎选择非常重要，新手最容易犯的错误就是选错引擎。默认情况下，如果你执行CREATE TABLE不指定引擎，ClickHouse 会用Log引擎，但它适合临时数据，不适合分析场景。

OLAP 场景下最核心的引擎是MergeTree家族。底层的 MergeTree 是基础，不过实际生产更常用的是ReplacingMergeTree（去重）、SummingMergeTree（聚合）和ReplicatedMergeTree（复制表）。单机部署先用 MergeTree 就行。

我测试时用的建表语句大概是这样的：

CREATE DATABASE IF NOT EXISTS test; CREATE TABLE test.events ( event_date Date, event_time DateTime, user_id UInt64, event_type String, cost Float64 ) ENGINE = MergeTree() PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, user_id);

几个设计要点解释一下：

• PARTITION BY toYYYYMM(event_date)：按月分区。ClickHouse 查询时能直接跳过无关分区，对时间范围过滤非常友好。
• ORDER BY (event_date, user_id)：这是 MergeTree 最重要的排序键。它决定了分区内部数据的物理顺序，也是查询性能的核心。查询条件里高频出现的字段一定要放在排序键里。如果经常按 user_id 查，排序键里放 user_id 能让查询走稀疏索引，速度飞快。
• 字段类型尽量用整数类型，能用 UInt32 存的状态值别用 String 存。列式数据库对整数类型处理性能远高于字符串。

写入数据可以走INSERT INTO ... VALUES，不过如果你了解 ClickHouse 的批处理能力，建议用INSERT INTO ... SELECT或者通过 HTTP 接口批量导入。一次写入几千行对 ClickHouse 来说是大材小用，一次写几十万行也是秒级完成。

验证一下：

INSERT INTO test.events VALUES ('2025-06-01', '2025-06-01 10:00:00', 1001, 'click', 0.5); INSERT INTO test.events VALUES ('2025-06-01', '2025-06-01 10:05:00', 1002, 'purchase', 99.9);

4.2 典型 OLAP 查询验证

部署完成后，我习惯用一个简单但代表性的查询验证性能：

SELECT event_type, count() AS cnt, sum(cost) AS total_cost FROM test.events WHERE event_date >= '2025-06-01' GROUP BY event_type ORDER BY total_cost DESC;

这个查询扫描了整张表的event_date、event_type、cost三列，但因为列式存储，它只读这三列的数据，不会像行式数据库那样把整行都读出来。这就是 ClickHouse 在聚合查询场景下快的关键。

如果你想更直观地感受性能差异，可以在表里插入几百万行测试数据，然后和 MySQL 做同一个分组聚合查询对比。我实测过，单机 ClickHouse 在千万级数据上的 GROUP BY 查询大多在几百毫秒到一两秒之间，MySQL 同样的数据量又是另一番滋味。不过别拿“单行点查”来比，那不是 ClickHouse 的主场。

4.3 关键参数说明与调优入口

ClickHouse 的配置覆盖内存、线程、并发、网络等多个维度，调优前先理解几个关键项。

第一个是max_memory_usage。这个参数在users.xml或者users.d下配置，控制单个查询最大内存使用量，默认值是 10GB。如果你的服务器内存只有 8GB，默认值反而可能让单个查询直接把容器搞 OOM。建议保守一点，在 users.d 里显式设置一个上限。

第二个是max_threads。它控制单个查询执行的线程数，默认值为 CPU 核数。在 CPU 密集型聚合场景下可以手动调大，但如果服务器同时跑多个查询，盲目调大反而会因为线程频繁切换降低整体吞吐。

第三个是max_concurrent_queries。它控制同时执行的查询数，默认值 100。如果有多业务共享一个 ClickHouse，需要限制一下并发，避免某个大查询把资源全部占满。

配置文件修改后要生效，需要重启容器。不过 ClickHouse 也提供了一些在线调整配置的接口，比如：

SET max_memory_usage = 8000000000;

这是会话级别的临时设置，适合测试时快速调整，不会持久化。要想持久化，还得写配置文件。

我自己调优的原则是“一次只改一个参数，改完跑一遍典型压测”。很多新手喜欢同时改十个参数，结果性能变差了也不知道是哪个参数造成的。

5. 日常运维：配置修改、备份恢复与容器升级

5.1 修改配置的正确方式

前面提到 ClickHouse 支持config.d和users.d目录，这是官方推荐的可扩展配置方式。在 Docker 部署结构下，怎么正确改配置呢？

举个例子，你想给default用户设置密码并限制查询内存。可以在宿主机/opt/clickhouse/config/users.d/default.xml写入：

<clickhouse> <users> <default> <password>your_strong_password</password> <max_memory_usage>8000000000</max_memory_usage> </default> </users> </clickhouse>

然后：

docker compose restart clickhouse

配置就生效了。这种方式的妙处在于，你只在users.d里覆盖了想改的项，其他配置仍然来自镜像默认的users.xml。镜像升级后，默认配置可能会随版本更新，你的自定义配置依然生效，不会因为版本变化被重置。

注意改配置后要用docker exec -it clickhouse-server clickhouse-client连接测试一下，确认没有因为写错配置导致服务无法启动。如果改坏了，通过docker compose logs clickhouse查看错误日志定位问题。

5.2 备份恢复与整体迁移

ClickHouse 的备份方案，我分两种场景来聊。

第一种是单机数据的快速备份。最简单的方式是直接对宿主机上的数据目录打快照备份：

docker stop clickhouse-server tar czf clickhouse_data_backup.tar.gz -C /opt/clickhouse data docker start clickhouse-server

简单粗暴，但适合小数据量。注意备份前要停容器，否则数据文件可能处于不一致状态，尤其是正在 merge 分区的时候。

第二种是官方推荐的BACKUP命令。ClickHouse 从 21.x 版本开始内置了备份功能，可以备份到本地目录或 S3：

BACKUP DATABASE test TO File('/backup/test');

恢复用：

RESTORE DATABASE test FROM File('/backup/test');

这种方式比拷贝数据文件靠谱得多，因为是逻辑备份，不依赖具体目录和表引擎状态。如果配置了远程存储，备份到对象存储也更安全。

关于“整体迁移”，我遇到不少人问：能不能直接把 ClickHouse 的数据目录拷到另一台机器？结论是：如果版本完全一致、路径完全一致、表结构没有变化，拷数据目录这种方式在测试环境是可以用的，但生产环境不建议，容易遇到元数据和数据不一致的问题。更稳妥的方案是：旧库执行BACKUP，新库执行RESTORE，或者用clickhouse-client的INSERT INTO ... SELECT ... FROM remote(...)做跨节点的数据搬迁。后者不需要停服务，还能控制数据量分批同步，实操中我用得最多。

5.3 容器升级与回滚

Docker 部署最大的优势之一就是升级和回滚都很方便。升级步骤是这样：

1. 拉新镜像：docker pull clickhouse/clickhouse-server:25.3
2. 修改docker-compose.yml里的镜像版本号
3. 执行docker compose up -d，Compose 会检测到镜像变化，重新创建容器
4. 执行docker ps确认新容器启动成功，执行SELECT version();验证版本

如果升级后发现问题，回滚只需要把docker-compose.yml里的版本号改回旧版本，再执行一次docker compose up -d即可。

这里我提供一个额外的建议：升级前一定先备份数据目录，虽然 ClickHouse 一般能跨小版本升级，但跨大版本有可能出现表格式不兼容的情况，有备份就不慌。另外生产环境升级前，至少先在测试环境重复一遍同样的操作。

6. 常见问题排查与避坑记录

6.1 客户端连接不上的常见原因

现象一：连接 9000 端口失败，报Connection refused。

这个大概率是服务没起来，先看容器状态：docker ps -a，再看日志：docker logs clickhouse-server。如果日志里有DB::Exception: Cannot listen to 127.0.0.1:9000，说明宿主机端口被占用了，把冲突进程找出来，或者改 ClickHouse 的映射端口（比如9001:9000）。

现象二：能从容器内连接，但宿主机连不上。

检查 Docker 端口映射：docker port clickhouse-server，确认宿主机端口真的映射出去了。在 Windows 上，如果 Docker Desktop 用的是 WSL2，注意 Docker 容器端口映射到的是 WSL2 的 IP，而不是localhost，需要查一下 WSL2 的 IP 才能连通。

现象三：连接 8123 HTTP 端口返回 401。

说明配置了密码，但请求没带认证信息。用-u default:密码或者--data-binary 'password: 密码'就能解决。

6.2 容器重启数据丢失

这是新手最容易踩的坑。检查你的docker-compose.yml，有没有给/var/lib/clickhouse挂载宿主机目录。没有挂载的话，容器一删，全部数据消失。

如果你不小心已经删了容器，但宿主机上确实挂载过数据目录，那还有救：新容器挂载同一个目录，启动后数据就能恢复。如果连目录都没挂载，那数据基本找不回来了，这也是为什么我反复强调数据目录一定要显式挂载。

还有一个小坑：如果目录权限不对，容器启动会失败。ClickHouse 容器内的运行用户是clickhouse（UID 101），所以宿主机上挂载的数据目录最好 chown 成 101:101：

chown -R 101:101 /opt/clickhouse/data

6.3 Windows 上 Docker Desktop 的坑

Windows 上用 Docker Desktop 跑 ClickHouse，最大的问题不是 ClickHouse 本身，而是 Docker Desktop 的环境问题。

如果你看到 Docker Desktop 启动失败，提示virtualization support not detected，第一检查 BIOS 虚拟化，第二检查 Windows 功能里“虚拟机平台”是否开启，第三把 WSL2 更新到最新。这三步做完，90% 的启动问题都能解决。

另外 Windows 上文件 IO 比 Linux 慢，如果你挂载的是 NTFS 目录，ClickHouse 的 merge 速度会明显变慢。测试可以接受，生产环境还是老老实实用 Linux 服务器吧。

6.4 镜像下载慢与网络问题

部署中很常见的一个障碍是 Docker Hub 镜像拉取慢。推荐配置镜像加速器，在/etc/docker/daemon.json里写：

{ "registry-mirrors": ["https://你的加速器地址"] }

然后执行sudo systemctl restart docker。不同镜像加速器可用性差异挺大，可以自己测试后选一个速度稳定的。如果拉取还是很慢，也可以考虑从 CDN 或内网仓库拉镜像。

还有一个网络相关的点：如果 ClickHouse 容器要访问宿主机上的 MySQL、PostgreSQL 或者达梦数据库，容器内不能用localhost，因为localhost指向容器自己。要用宿主机在 Docker 网络里的 IP，比如172.17.0.1这种网关地址。用 Docker Compose 部署时，也可以用容器名作为主机名来互相访问。

拉取遇到临时网络问题导致层下载不全时，删掉半成品镜像重新拉一次通常能解决：

docker rmi clickhouse/clickhouse-server:25.3 docker pull clickhouse/clickhouse-server:25.3

6.5 常见问题速查表

7. 后续扩展方向

单机部署跑通之后，你可以沿着几个方向继续深入。

第一个是上副本。ClickHouse 单机节点一旦宕机，所有查询都会中断。生产环境至少要用ReplicatedMergeTree加两副本，搭配 ClickHouse Keeper 做分布式协调。Docker 部署多节点依然可以用 Compose 编排，每个节点挂不同的数据目录，端口分开映射。

第二个是上分片。当单机存储和计算能力不够时，用Distributed表引擎做分布式查询。分片能解决数据量级扩展的问题，但也带来了数据分布倾斜、跨节点 join 效率等问题，建议在业务真正需要时再上。

第三个是打通数据管道。ClickHouse 在真实场景中很少孤立运行，它通常和消息队列、数据采集工具配合。比如用 Vector、Fluent Bit 采集日志写入 ClickHouse，或者用 Kafka 引擎表把实时流数据接入。这些组件用 Docker Compose 一次性编排起来，能直接搭出一个轻量级实时数仓原型。

我自己目前的规划是在这套 Docker 部署基础上，搭建一套完整的监控告警体系，把 ClickHouse 的查询性能、磁盘占用、merge 队列长度都采集起来，用 Grafana 做可视化面板。数据库搭起来只是开始，真正考验人的是后续容量规划和稳定性保障。

最后再分享一个小技巧：ClickHouse 的system库非常有用，查询system.tables、system.parts、system.processes能直接看到当前库里的表、分区和数据量，还有正在执行的查询状态。排查慢查询和磁盘占用问题的时候，这三个表就是你的第一手信息源，而且查询它们本身开销很小，不用怕影响线上业务。