目录前言一、SQL 语法坑一写就报错还找不到原因坑 1不支持连续比较 a x b坑 2WHERE 中不能使用 SELECT 别名坑 3JOIN 不注意左右表直接 OOM (Out Of Memory) 内存溢出二、建表引擎坑主键、排序、分区错一个性能掉 100 倍坑 4主键 PRIMARY KEY ≠ 唯一约束坑 5ORDER BY 排序键乱设查询全表扫描坑 6分区太细直接触发 Too many parts三、写入坑90% 集群崩溃都源于此坑 7单条高频 INSERT必崩集群坑 8滥用 UPDATE / DELETEMutation 堆积四、查询性能坑慢查询都是自己写出来的坑 9SELECT * 杀手坑 10索引字段上用函数索引直接失效坑 11滥用 Nullable性能暴跌五、运维坑配置不对随时宕机坑 12机械硬盘、开 Swap、文件句柄太小总结ClickHouse 10 条铁律前言大部分问题本质只有一个把 ClickHouse 当 MySQL 用。ClickHouse 是列式存储 OLAP 引擎不是行存 OLTP 数据库思维不转变踩坑是必然的。这篇文章把生产环境最容易遇到的12 个真实踩坑一次性讲透看完少走几个月弯路。一、SQL 语法坑一写就报错还找不到原因坑 1不支持连续比较 a x b这是新手最容易踩的语法坑复制 MySQL 写法直接报错。错误写法SELECT * FROM order_info WHERE 1000000 pay_amount 5000000;正确写法SELECT * FROM order_info WHERE pay_amount 1000000 AND pay_amount 5000000;原因ClickHouse 语法解析器不支持链式比较必须拆成两个条件用 AND 连接。坑 2WHERE 中不能使用 SELECT 别名很多人习惯在 WHERE 里用别名ClickHouse 直接不认。错误写法SELECT id, price * 1.1 AS total FROM order_info WHERE total 1000;正确写法-- 方式1重复表达式简单场景推荐 SELECT id, price * 1.1 AS total FROM order_info WHERE price * 1.1 1000; -- 方式2子查询复杂计算推荐 SELECT id, total FROM ( SELECT id, price * 1.1 AS total FROM order_info ) t WHERE total 1000;原因ClickHouse 执行顺序FROM → WHERE → GROUP BY → SELECT → ORDER BY别名在 SELECT 阶段才生成WHERE 根本看不到。坑 3JOIN 不注意左右表直接 OOM (Out Of Memory) 内存溢出ClickHouse JOIN 有一个铁律右表会被全量加载到内存。错误写法-- 大表放右边内存直接爆 SELECT * FROM big_table JOIN small_table ON big_table.id small_table.id;正确写法-- 小表放右大表放左 SELECT * FROM small_table JOIN big_table ON small_table.id big_table.id;分布式表必须加 GLOBALSELECT * FROM small_table GLOBAL JOIN big_table ON ...不加 GLOBAL每个节点只 join 本地分片结果会少一半。二、建表引擎坑主键、排序、分区错一个性能掉 100 倍坑 4主键 PRIMARY KEY ≠ 唯一约束这是 ClickHouse 最大的认知误区。真相MergeTree 主键只用来建索引不做唯一性校验重复数据可以随便写。解决方案写入侧保证幂等最优使用 ReplacingMergeTree 异步去重查询时加 DISTINCT / GROUP BY坑 5ORDER BY 排序键乱设查询全表扫描ORDER BY 是 ClickHouse 性能灵魂决定数据物理存储顺序和索引结构。规范高频过滤字段必须放在最左侧主键必须是排序键的前缀字段数量控制在3~5 个反面教材ORDER BY (name, id, create_time, amount);推荐结构ORDER BY (create_time, user_id, id); PRIMARY KEY (create_time, user_id);坑 6分区太细直接触发 Too many parts严禁按小时、分钟、秒分区分区过多会产生大量小文件后台合并不过来最终拒绝写入。推荐分区策略PARTITION BY toDate(create_time) -- 按天 -- 或 PARTITION BY toYYYYMM(create_time) -- 按月三、写入坑90% 集群崩溃都源于此坑 7单条高频 INSERT必崩集群ClickHouse 是批量写入设计单条循环写入会瞬间产生大量 part。禁止写法INSERT INTO t VALUES(1,...); INSERT INTO t VALUES(2,...);生产标准单次写入10w ~ 100w 行频率控制在1~2 秒一次使用批量 VALUESINSERT INTO t (id,time) VALUES (1,2026-04-01 10:00:00), (2,2026-04-01 10:00:01);坑 8滥用 UPDATE / DELETEMutation 堆积ClickHouse 的 UPDATE/DELETE 是异步 Mutation 重分区不是实时行级操作。风险改 1 行也重写整个分区高频执行会导致Too many mutations无法回滚、无事务原则能不更新就不更新必须更新只做批量、低频、冷数据操作。四、查询性能坑慢查询都是自己写出来的坑 9SELECT * 杀手列存数据库读越多列越慢。** 永远不要 SELECT ***只查需要的字段。坑 10索引字段上用函数索引直接失效错误WHERE toDate(create_time) 2026-04-01正确WHERE create_time 2026-04-01 00:00:00 AND create_time 2026-04-02 00:00:00坑 11滥用 Nullable性能暴跌Nullable 字段会多存 1 字节标志位压缩率下降索引效率降低聚合、排序变慢能用默认值就不要用 Nullable。五、运维坑配置不对随时宕机坑 12机械硬盘、开 Swap、文件句柄太小必须用 SSD机械盘合并速度跟不上必须关闭 Swap否则极易 OOM文件句柄调到 100w副本 ≠ 备份误删数据无法恢复必须定期 BACKUP总结ClickHouse 10 条铁律不支持连续比较必须拆成 ANDWHERE 不能用 SELECT 别名JOIN 小表放右分布式加 GLOBAL主键不保证唯一靠写入幂等排序键最左放高频过滤字段按天 / 月分区禁止小时分区禁止单条高频写入禁止频繁 UPDATE/DELETE禁止 SELECT *禁止索引字段加函数必须 SSD、关 Swap、做备份你在使用 ClickHouse 过程中还踩过哪些奇葩坑欢迎评论区留言