min_chunk_bytes_for_parallel_parsing
- 类型：无符号整数
- 默认值：1 MiB
min_compress_block_size
min_compress_block_size，就会对该块进行压缩。默认值为 65,536。
如果未压缩数据小于 max_compress_block_size，则块的实际大小不会小于该值，也不会小于一个标记对应的数据量。
我们来看一个示例。假设在创建表时将 index_granularity 设为 8192。
假设我们写入的是一个 UInt32 类型的列 (每个值 4 字节) 。写入 8192 行时，总数据量为 32 KB。由于 min_compress_block_size = 65,536，因此每两个标记会形成一个压缩块。
假设我们写入的是一个 String 类型的 URL 列 (每个值平均 60 字节) 。写入 8192 行时，平均数据量会略小于 500 KB。由于这大于 65,536，因此每个标记都会形成一个压缩块。在这种情况下，从磁盘读取单个标记范围内的数据时，不会额外解压其他数据。
这是一个专家级设置；如果你刚开始使用 ClickHouse，不建议修改它。
min_filtered_ratio_for_lazy_final
0 会禁用此检查。
min_hit_rate_to_use_consecutive_keys_optimization
min_os_cpu_wait_time_ratio_to_throw
OSCPUWaitMicroseconds 指标) 与忙碌时间 (OSCPUVirtualTimeMicroseconds 指标) 之间的最小比率。概率通过最小比率与最大比率之间的线性插值计算；当比率处于该值时，概率为 0。
min_outstreams_per_resize_after_split
Resize 或 StrictResize 处理器的最少输出流数量。如果生成的流数量小于该值，则不会执行拆分操作。
什么是 Resize 节点
Resize 节点是查询管道中的一种处理器，用于调整管道中数据流的数量。它既可以增加流的数量，也可以减少流的数量，从而在多个线程或处理器之间平衡工作负载。例如，如果查询需要更高的并行度，Resize 节点可以将单个 stream 拆分为多个流。反过来，它也可以将多个流合并为更少的流，以集中处理数据。
Resize 节点可确保数据在各个流之间均匀分布，同时保持数据块的结构。这有助于优化资源利用率并提升查询性能。
为什么需要拆分 Resize 节点
Resize 节点，其 ExecutingGraph::Node::status_mutex 会出现严重争用，尤其是在高核数环境下。这种争用会导致：
- ExecutingGraph::updateNode 的延迟升高，直接影响查询性能。
- 大量 CPU 周期浪费在自旋锁争用 (native_queued_spin_lock_slowpath) 上，降低整体效率。
- CPU 利用率下降，限制并行度和吞吐量。
Resize 节点如何拆分
- 首先会检查输出流数量，以确保可以执行拆分：每个拆分后处理器的输出流都必须达到或超过
min_outstreams_per_resize_after_split阈值。 Resize节点会被拆分为多个更小的Resize节点，这些节点的端口数量相同，每个节点分别处理一部分输入流和输出流。- 各组会独立处理，从而减少锁竞争。
拆分具有任意输入/输出的 Resize 节点
Resize 节点数整除，就会将部分输入连接到 NullSource，并将部分输出连接到 NullSink。这样就能在不影响整体数据流的情况下完成拆分。
设置的用途
min_outstreams_per_resize_after_split 设置可确保对 Resize 节点进行拆分是有意义的，并避免生成过少的流，因为这可能导致并行处理效率低下。通过强制设定输出流的最小数量，该设置有助于在并行度与开销之间保持平衡，从而在涉及流拆分与合并的场景中优化查询执行。
禁用该设置
Resize 节点的拆分，请将此设置设为 0。这样会阻止在管道生成期间拆分 Resize 节点，使其保留原有结构，而不会被拆分为更小的节点。