Clickhouse 表 MergeTree 引擎不断填充“INSERT INTO ... FORMAT CSV”查询，从空开始。平均输入速率为每秒 7000 行。插入以几千行为单位进行。当同时执行 SELECT 查询时，这会对性能产生严重影响。如 Clickhouse 文档中所述，系统最多需要 10 分钟来合并特定表的数据（重新索引）。但这并没有发生，因为表格是不断填充的。
这在文件系统中也很明显。表文件夹有数千个子文件夹，索引被过度分割。如果数据摄取停止，几分钟后表格完全合并，子文件夹的数量变为十几个。
为了遇到上面的弱点，使用了 Buffer Engine 来缓冲表数据摄取 10 分钟。因此，缓冲区的最大行数平均为 4200000。
初始表最多延迟 10 分钟，因为缓冲区保留了最近摄取的行。该表最终被合并，其行为与表已停止填充几分钟的情况相同。但是对应于缓冲区和初始表的组合的缓冲区表正在变得严重变慢。
从上面可以看出，如果表是连续填充的，则它不会合并，并且索引会受到影响。有没有办法避免这个弱点？
表数据目录中的子文件夹数量并不是那么具有代表性的值。
实际上，每个子文件夹都包含一个由排序（索引）行组成的数据部分。如果几个数据部分合并为一个新的更大的部分，则会出现新的子文件夹。
但是，合并后不会立即删除源数据部分。有一个<merge_tree>设置old_parts_lifetime定义了一个延迟，之后部件将被移除，默认设置为 8 分钟。此外，还有一个cleanup_delay_period设置定义了后台清理器检查和删除过时部件的频率，默认为 30 秒。
因此，在摄取开始后大约 8 分 30 秒内有这样数量的子文件夹是正常的。如果您无法接受，您可以更改这些设置。
仅检查表中活动部分的数量是有意义的（即尚未合并到更大的部分中的部分）。为此，您可以运行以下查询：SELECT count() FROM system.parts WHERE database='db' AND table='table' AND active.
此外，如果分区中的活动部分的数量大于 ，ClickHouse 会在内部进行此类检查parts_to_delay_insert=150，它会减慢 INSERT，但如果大于parts_to_throw_insert=300，它将中止插入。