导读：ClickHouse速度快的秘诀在于——利用存储引擎的特殊设计充分减少磁盘I/O对查询速度的影响。
ClickHouse为什么查询速度快？本文来揭秘。
1、预排序
ClickHouse与传统事务数据库的一个不同之处在于ClickHouse写入数据文件的数据时有序的，这就是本节将要介绍的预排序：将数据在写入磁盘前进行排序，以保证数据在磁盘上有序。
预排序在数据库系统是一个被广泛使用的技术，在实现范围查找时，可以将大量的随机读转换为顺序读，从而有效提高I/O效率，降低范围查询时的I/O时间。在点查找时，预排序能做到和未排序数据相同的性能。因此，预排序可以在不降低点查找性能的情况下，有效提高范围查询的性能。
2、列存
列存数据库和行存数据库根本的区别在于列存数据库将一行数据拆分到多个数据文件中。在列存数据库中，同一列的所有数据都在同一个文件中，因此在硬盘上是连续的。这种特性特别适合OLAP的低范式查询场景。
3、压缩
ClickHouse的另一个降低I/O的手段是压缩，压缩可以减少读取和写入的数据量，从而减少I/O时间。并不是所有场景下都可以引入压缩的，很显然，压缩必然带来压缩和解压缩的CPU消耗，这是一个利用CPU时间换I/O时间的手段。事务数据库由于大部分情况下是针对行的操作，因此如果对每一行都进行一次压缩解压缩，带来的时间消耗是远大于磁盘I/O时间的。这就是事务数据库没有使用压缩技术的原因。
而ClickHouse则不同，ClickHouse的小处理单元是块，块一般由8192行数据组成，ClickHouse的一次压缩针对的是8192行数据，这就极大降低CPU的压缩和解压缩时间。同时，ClickHouse是列存数据库，同一列的数据相对更有规律，因此能够带来比较大的压缩比。因此，块+压缩在ClickHouse中成为一个非常关键的优化手段。
1、 ClickHouse速度快的前提
在正式进入本节内容之前，我们首先需要明确一个前提：ClickHous不是在所有场景下都能获得很强的性能。因此，需要先分析ClickHouse在满足哪些前提下才能获得强的查询性能。
ClickHouse计算引擎精妙的设计在于向量化引擎，那么ClickHouse由于计算引擎原因导致的快，肯定是来自向量化引擎的加持。而ClickHouse的计算引擎导致的慢是因为缺乏代价优化器，那么由于计算引擎导致的慢也来自缺乏代价优化器带来的缺陷。基于这两个逻辑，我们可以分析出ClickHouse速度快的前提。
1）大量使用向量化运算
ClickHouse提供了很多内置函数，在使用这些内置函数时，ClickHouse会自动进行向量化优化。因此尽可能使用提供的内置函数进行计算，而不是自己写SQL语句。下面展示错误的SQL写法以及正确的写法。
SELECT (2/(1.0 + exp(-2 * x))-1) as tanh_x …… // 错误的写法SELECT tanh(x) as tanh_x …… // 正确的写法，直接使用ClickHouse的内置函数2）查询语句中没有使用Join子句，或尽可能少的使用Join操作
ClickHouse没有代价优化器，这导致了ClickHouse在Join操作时会出现内存不足等情况，导致查询失败。Join的性能问题其实并不仅仅是ClickHouse才遇到，任何数据库在遇到大表Join时都有可能导致查询时间暴增。
大数据中的Spark计算引擎对Join操作做了非常多的优化，借助其强大的CBO实现了Join算法的自动选择。更是在此基础上，通过AQE（Adaptive Query Execution,自适应查询引擎），解决了大表Join操作时遇到数据倾斜时的性能问题。
正是由于ClickHouse没有实现CBO，因此ClickHouse在实现Join操作时，选择余地很少。尤其是分布式大表Join操作时，ClickHouse只实现了广播连接（Broadcast Join）算法，极大地降低了ClickHouse的Join能力。
在使用ClickHouse时，应当尽可能避免Join操作。而Join操作在ODS建模的过程中大量存在。因此，ClickHouse在设计良好的DW上运行向量化查询的性能高。读者应该尽可能避免将ClickHouse用于ODS的建模工作中。当数据量大时，这类建模工作还是尽可能下推到Spark上执行。
2、ClickHouse快的本质
使用MergeTree存储引擎。 按照业务需求，正确设置数据表的排序键，查询时需满足左原则。
没有或少用Join操作。 -
尽可能多地使用内置函数。
