【 TiDB 使用环境】
【概述】：场景 + 问题概述
TiKV的 rocksdb 的 defaultcf.block-size和writecf.block-size都是64K 并且默认开启压缩，请问在压缩的时候是以 64KB 为单位进行压缩吗？
压缩后的大小必然不同块会有一些不一样大，写到文件的时候是原有block 每个一个IO写出还是会将很多压缩后的block合并到指定大小后再一次IO 写出？
如果是后者，请问这个大小大概多大？是哪个参数？
【背景】：做过哪些操作
无。
【现象】：业务和数据库现象
无。
【问题】：当前遇到的问题
【业务影响】：
【TiDB 版本】：5.4
【TiDB Operator 版本】：
【K8s 版本】：
【附件】：
[rocksdb.defaultcf]
# 数据块大小。RocksDB 是按照 block 为单元对数据进行压缩的，同时 block 也是缓存在 block-cache
# 中的最小单元（类似其他数据库的 page 概念）。
block-size = "64KB"
# RocksDB 每一层数据的压缩方式，可选的值为：no,snappy,zlib,bzip2,lz4,lz4hc,zstd。
# no:no:lz4:lz4:lz4:zstd:zstd 表示 level0 和 level1 不压缩，level2 到 level4 采用 lz4 压缩算法,
# level5 和 level6 采用 zstd 压缩算法,。
# no 表示没有压缩，lz4 是速度和压缩比较为中庸的压缩算法，zlib 的压缩比很高，对存储空间比较友
# 好，但是压缩速度比较慢，压缩的时候需要占用较多的 CPU 资源。不同的机器需要根据 CPU 以及 I/O 资
# 源情况来配置怎样的压缩方式。例如：如果采用的压缩方式为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量
# 写入数据的情况下（导数据），发现系统的 I/O 压力很大（使用 iostat 发现 %util 持续 100% 或者使
# 用 top 命令发现 iowait 特别多），而 CPU 的资源还比较充裕，这个时候可以考虑将 level0 和
# level1 开启压缩，用 CPU 资源换取 I/O 资源。如果采用的压缩方式
# 为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量写入数据的情况下，发现系统的 I/O 压力不大，但是 CPU
# 资源已经吃光了，top -H 发现有大量的 bg 开头的线程（RocksDB 的 compaction 线程）在运行，这
# 个时候可以考虑用 I/O 资源换取 CPU 资源，将压缩方式改成"no:no:no:lz4:lz4:zstd:zstd"。总之，目
# 的是为了最大限度地利用系统的现有资源，使 TiKV 的性能在现有的资源情况下充分发挥。
原说明文档如下：
https://docs.pingcap.com/zh/tidb/stable/tune-tikv-memory-performance#参数说明
我也看到了这个，如果是这样，那写IO 大小就会普遍很小且不规律，感觉总有点不够优化。
咱们还有个开发者社区，如果有好的建议和疑问，可以在开发者社区一起讨论
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。