内存放大的许多因素:
- chunk 编码会导致数据放大,不同类型放大倍数不一样,其实 decimal 是放大比例很高的
- RPC 消息读取之后，是一整块的内存，包含了不少 chunk，然后释放机制是，只有里面所有 chunk 消费完之后，这整块内存才释放.(比如说有 100 个 chunk，哪怕其中 99 个消费掉了,还有一个 chunk 被引用着,则整块内存无法释放)
- tidb_distsql_scan_concurrency这个参数，并发是一块，实际上还带了 channel 的，数据并发读上来并不是立刻消费,而是往 channel 写，由消费者去读 channel 消费. 由于 channel 的存在，实际的内存占用就不仅受并发控制，还有 channel size 的影响
- 除了读数据这一层的并发,有部分算子的处理是带内部并发的,这些算子内部并发"正在消费"中的 chunk 也会成为内存放大的因素
然后是关于放大倍数的
https://github.com/pingcap/tidb/issues/35633 这里是 coprocessor paging 的开发记录
其中文档 https://pingcap.feishu.cn/docs/doccnPKxuP3LiOBI5HaSPO4Idtc 有部分的数据
chunk vs 非chunk 大小对比
发现 decimal 放大最严重：2603116 vs 10410316
bigint not null 的时候，chunk 要优于非 chunk，占用更小的包大小： 2342962 vs 2084880
varchar(150) 的时候，chunk 占用的比非 chunk 略高：5205162 vs 6770230
varchar(1) 的时候，chunk 是非 chunk 的近 3 倍：782036 vs 2347106