前言
本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见大数据技术体系
1. 配置优化
ClickHouse 的通用优化配置如下表所示，大部分配置需要根据线上实际楼况进行优化，具体需要优化的配置可参考官方文档：
https://clickhouse.tech/docs/en/operations/settings/query-complexity
https://clickhouse.tech/docs/en/operations/settings/
| 配置名 | 推荐配置 | 说明 |
|---|---|---|
| max_server_memory_usage_to_ram_ratio | 机器内存的 90% | 占用物理机内存比例 |
| max_memory_usage | 根据单查询内存使用量和并发合理调整 | 单查询最大使用内存量 |
| background_pool_size | CPU 核心数的两倍 | 后台 Merge 操作的线程数 |
| max_parts_in_total | 1000000 | 单机最大part个数 |
| parts_ to_delay_insert | 3000 | 单个分区下的活跃 part 数超过该值后，会延迟新的写人 parts_to_throw_insert |
| old_parts_lifetime | 0表示立即删除旧的part, 根据业务需求调整 | 后台合并和数据过期后旧的 part 保留的时间 |
| max_ concurrent_queries | 根据机器资源调整 | 某个 MergeTree 的最大查询数 |
| max_bytes_before_external_group_by | 推荐开启，具体值为 max_memory_usage 的一半 | Group by 过程允许数据落盘 |
2. 查询优化
用户在查询数据时，可以参考如下几点对 SQL 进行优化：
- 通过 explain 命令来查看执行计划，确认查询计划是否合理。
- 先过滤数据（减少I/O）再进行 join 等操作。
- join 操作，大表在前，小表在后。
- 建议使用大宽表进行查询，不要进行多次 join。
- 业务允许时，可以使用近似函数代替精确函数，例如用 uniq 代替 count distinct
- 两张分布式表进行 join 时，可以在写人数据前，按照相同规则分片(shard）到相同节点。
- 子查询为分布式表时，需要使用 GLOBAL 关键宇。
3. 表相关优化
用户在创建表时，可以参考如下几点：
- 尽量不用 string 类型的字段。
- 使用默认值代替空值。
- 能进行分区的事实 表尽量进行分区。
- 可以使用二级索引。
- 业务允许的价况下配器 TTL，删除不必要的数据。
- 尽量做 1000 条以上的数据写人，诚少后台 Merge 压力。