为什么加上insert into 就不用tiflash

两个表join 表都建了tiflash副本 如果只有select语句 看执行计划是走的tiflash 但是如果在前面加上insert into 就变成tikv了 何解
tidb版本5.4

2赞

具体sql可以发一下。
tiflash只负责读操作。
写操作还需要去tikv.

是这样的

4赞

tiflash主要是为了处理ap的业务,写入操作走tikv也正常,一般insert into select也不会写复杂的查询。

2赞

但是这个限定导致了下面这个场景
如果需要将多个表join后统计再将结果保存下来
使用tikv的效率会比使用tiflash差很多,需要应用测发起一个查询再从客户端调用insert into 入库 岂不是很曲折 结果还是从tiflash完成查询再放到数据库里结果数据库本身不支持

2赞

这个限定在tidb5.4的时候还是这样吗?有没有配置可以使用tiflash

1赞

是的,我在生产环境也遇到了同样的问题。我找了官方,得到的回复:目前还不能走tiflash。
所以,只能用其他方式规避。比如针对select必须走tiflash的insert语句,可以用脚本使用dumpling导出,再用load data导入,或者select查到内存中,然后insert,但是这样要注意内存的使用,应用端容易oom

3赞

insert into 是写操作。
tikv与tiflash的关系。是tifalsh以learning角色加入raftgroup中,从tikv的region中t同步数据,目前tiflash不支持写。

2赞

写是在其他的表上并不是在tiflash上写啊 tiflash是负责查询准备写入的数据还是一个只读操作

2赞

insert into 就会被认定为写操作,写入就会走到tikv了

1赞

很多应用都是这样使用的,期待后续版本能有一些解决方案

2赞

insert into select 属于高IO,并且是在OLTP中较多,直接读取TiKV更合适吧

2赞

考虑一下这个场景一个大宽表和一个维表连接后 在某个指标列上聚合了一下把结果放到另一个指标表里 最tiflash可以省下几十倍的IO最后写入的数据并不大

2赞

insert into是写动作,尽管你后面有select。
写动作都是到tiKV的

2赞

临时存储,不考虑内存临时表?还有存储TiKV的RocksDB写入也是在memstore也是内存中,只有合并才会写入磁盘啊

2赞

目前确实是不会走,原因是如果走 tiflash 会有一些一致性的问题,有计划在后续版本中解决这个问题,但还不能确定时间点 :upside_down_face:

3赞

大佬,请问是否可以理解为,TiFlash现在是raft learner机制,其实就是tikv的只读副本,所以涉及写操作都会直接走tikv,也无法通过加hint让写走TiFlash。

2赞

是的,你理解的很到位。
目前 TiDB 不支持独立存在的 TiFlash 副本,也不支持把更新直接写入 TiFlash。TiFlash 的所有数据更新入口都是从 TiKV 同步。

3赞

收到,谢谢~

2赞