Tiflash COMPACT 背后的逻辑是什么?

从6.0升级到了6.1,然后执行了 ALTER TABLE net_online COMPACT tiflash replica; 随后性能飙升,9亿数据的十几秒查询提升到了2秒出结果;想请教下COMPACT背后的逻辑是什么?

TiFlash Major Compaction是将Delta层的数据与磁盘上Stable层的数据进行合并,结构上有点类似于一个2层的LSM-Tree。另外还有一个Minor Compaction的概念,就是DeltaTree后台持续对零碎的、小的ColumnFileTiny进行合并,合成一个大的ColumnFileTiny

请教一下,除了提升速度,有看到什么不稳定或者副作用吗?其他的表上也能有类似效果吗?

原理是这样:
TiFlash 本身会自动在后台执行 compact 操作,compact 操作会优化数据文件的组织形态,回收已经过期的数据版本,所以能提高查询性能。但是自动执行的 compact 是有一定的触发阀值的,比如 delta 数据量操作一定大小才会触发,否则就会产生很大的写放大。也就是说,如果一张表没人任何数据写入了,虽然它的数据形态不是最优的,但是 TiFlash 也不会去自动 compact 它。

这次提供的手动 compact 命令,和后台自动 compact 做的事情其实是一样的,只不过可以通过 SQL 主动触发。所以它没事副作用,唯一的影响是它在运行的生活会消耗一定的系统资源。目前默认只有 1 个并行度

通常手动 compact 用于不频繁更新的表,比如每天导入一次,然后 compact 一下。对于频繁更新的表,手动 compact 之后对性能的影响不太明显(因为 TiFlash 自己就会做了),当然跑一下也没啥问题。

https://docs.pingcap.com/zh/tidb/stable/sql-statement-alter-table-compact#alter-table--compact