总结如下 同一层级不允许使用两个及两个以上的（非LEFT/INNER）JOIN，除非所有都是LEFT JOIN/INNER JOIN。 ClickHouse会把同一层多个JOIN的语句重构成多层，每一次只会有一个JOIN。常规情况下数据表都会在第一个，在此前提下只要出现至少一个 RIGHT JOIN、FULL JOIN，那么WHERE条件就不会下推导第一层JOIN，从而会出现数据表被全表做JOIN的情况，从而使性能急剧下降。 不推荐通过对数据表单独封装子查询的方案原因为，在维度表用的是local表时，此方案会造成数据不准，具体详见CH查询逻辑 ClickHouse多个同层JOIN的使用优化 ClickHouse
可对映射表在CH的SQL使用的做以下的最简洁的规范 所有映射表作为驱动表时无须用子查询封装，但作为被驱动表时一律用子查询进行封装（简化规范，保持一致性） 在SELECT中只提取需要用到的字段（减少字段数来降低的网络IO，及内存使用） 在WHERE语句中尽可能的提前过滤字段，但不能对字段做CH的函数处理（减少记录数来降低的网络IO，及内存使用） ClickHouse中MySQL(TiDB)的映射表的使用优化 ClickHouse
此篇作为开端，即是引题又是总结，后续会在陆续发布不同角度优化的探索过程 整体来说，ClickHouse的性能，但这些都是基于优化后的结果，一条优化过的SQL与没有经过优化的SQL的性能可能会相差好几倍。 SQL慢查大部分主要体现在CPU负载过高，IO（磁盘IO/网络IO）过高，或者查询的列中无索引导致的。 对于ClickHouse的优化可以从表结构存储设计优化与查询SQL优化两个方向来进行。此篇先只针对查询SQL优化的方向进行整理，大致有以下几个方向 在WHERE语法只过滤出必要的记录。 在SELECT中只选择必要的字段。 尽可能的提前做运算，降低网络IO成本。 注意JOIN语句的不合理使用造成的数据量爆炸（过度放大）。 对于MySQL(TiDB)的映射表使用，结合1，2两点做子查询封装。 所有映射表作为驱动表时无须用子查询封装，但作为被驱动表时一律用子查询进行封装（简化规范，保持一致性） 在SELECT中只提取需要用到的字段（减少字段数来降低的网络IO，及内存使用） 在WHERE语句中尽可能的提前过滤字段，但不能对字段做CH的函数处理（减少记录数来降低的网络IO，及内存使用） .... ClickHouse的SQL优化概览 ClickHouse
最近在开发任务服务，其中有一个任务上报模块。其业务逻辑如下： 1.上报子任务详情，更新数据库 2.根据子任务状态同步总任务状态，实时更新任务进度。 最简单的实现方式就是UpdateSubTask,UpdateTask。 显然，这种方式并发情况下会有问题。 优化一 1.对子任务id进行分布锁，这里记得上锁时要添加超时时间，不然死锁就完犊子了。 func (impl *RedisCache) Lock(ctx context.Context, key string, expiration time.Duration) error { ok, err := impl.r.SetNX(impl.getKey(key), 1, expiration).Result() if err != nil { return err } if !ok { return errors.New("redis lock: already locked") } return nil } func (impl *RedisCache) Unlock(ctx context.Context, key string) e.... 任务服务的一次优化 优化
Fancy的技术博客