truncate操作是同步操作。你不等truncate执行完就另外session执行load data，本身自己程序逻辑就存在问题吧。

tidb就算做mpp其实也是在tidb-server上做，不可能在tikv上做。

好的，感谢！

请教下，这个storage read batches（storage write batch）是和如下这个参数相关么： [image]

请教下，这里tikv的iters的行为和tidb侧的loop是一样的么？

还是应了那句话，只要想到的早晚会遇到，果然在目前生产上就遇到类似的问题了。在其它老牌数据库中迁移过来的存在较多这种关联字段中包含or条件的，在发帖子当时测试OB时候它的优化器就能做到改写。我们目前也只能通过人工改写的方式来进行优化，改写逻辑大体如下： select a.c1,b.c2 from a,b where a.c1=b.c1 or a.c2=b.c2 改为方式为： select a.pk,b.pk,a.c1,b.c2 from a,b where a.c1=b.c1 union select a.pk,b.pk,a.c1,b.c2 from a,b where a.c2=b.c2…

在数据库server中使用kill命令没问题，在客户端直接终止程序不行，之前提过需求，不过终于在7.5实现了。

在7.5之前版本，在客户端直接杀掉进程后会数据库还会继续完成语句。如果正在执行大事务， 如果是自动提交则会事务执行成功，如果非自动提交事务会rollback，锁会自动释放。 在7.5版本，客户端杀掉进程后，数据库直接终止，语句立刻被kill掉，事务会回滚，锁也会释放。 [image]

当remove掉一个ID后，在INFORMATION_SCHEMA.RUNAWAY_WATCHES中还存在，但是在mysql.tidb_runaway_watch中不存在了。 [image] 感觉对于remove时候查询的是mysql.tidb_runaway_watch，在监控的时候查询的是INFORMATION_SCHEMA.RUNAWAY_WATCHES。

我重新完整的复现了下： 1、做tpch1的数据加载： tiup bench tpch -H 192.168.31.201 -P 4000 -U root -p123 -D tpch1 prepare --sf=1 2、修改默认Resource Group： ALTER RESOURCE GROUP default QUERY_LIMIT=(EXEC_ELAPSED='100ms', ACTION=KILL, WATCH=EXACT DURATION='10m'); 3、执行并发请求程序（程序见附件 main.go (1.8 KB) ）： go run main.go -h…

我直接安装8.1版本，然后重新做了测试。如果加一条QUERY WATCH，可以kill掉，然后多执行几次就会复现了。只要出现了一次，后面就无法删除了。

我这里是从7.5.1升级上来的，每次都必现。如下： ALTER RESOURCE GROUP default QUERY_LIMIT=(EXEC_ELAPSED='1h', ACTION=KILL, WATCH=PLAN DURATION='10m'); QUERY WATCH ADD RESOURCE GROUP default SQL text SIMILAR to 'select count(*) from tpch1.customer'; SELECT * FROM INFORMATION_SCHEMA.RUNAWAY_WATCHES ORDER BY id; query watc…

从慢日志文本中有RU相关信息： [image] 但是dashboard中并没有这个信息： [image] 是否算是dashboard的一个小小的BUG？

不做raid的最大问题就是换盘然后操作系统、软件都需要配合，如果系统多软硬件维护团队分离，不做raid是比较痛苦的。 根据我们经验利用intel+软raid方案磁盘损坏的概率更大，自从做了这个方案软raid的nvme盘故障率是其它方案的几倍高。 现在ssd已经很快了，比较建议raid+ssd方案。

看文档8.1版本开始import into语句支持了对as of timestamp导入历史版本数据的支持，例如： import into t from select * from customer as of timestamp date_sub(now(),interval 1 minute); [image] 点个赞！

这对你这个版本，跑批的相关的session，建议： 1、tidb_prepared_plan_cache_size按照默认值100设置即可。 2、确保该session跑批时候的语句种类不超过tidb_prepared_plan_cache_size，最好不超过10个，这样让这种insert into values很多行的情况可以常驻plancache，一定要注意不要和其它非批次业务混合跑，避免其它非批次语句执行过于频繁导致批次大语句被刷出plancache触发GC问题。 3、控制跑批语句的session是单独的连接（不要和正常的业务放在一个连接池，或者放在一起也不要释放连接，不然可能会污…

如果tidb的执行计划缓存中不存放和校验参数值的话，应该次次都可以用同一个缓存？ –是的 如果在缓存中存有执行时的参数绑定的话，那对于批量插入语句是不就是必然难以使用执行计划缓存？ –很难，因为你每次prepare的stmt都不一样了，因为你prepare时就把stmt搞成不同的了（带了参数值），所以会频繁的在执行计划中淘汰导致可能出现OOM。 而且insert语句的执行计划中会包含啥信息呢，它也不像查询类语句那样有不同路径 –执行时候并不会包含太多信息所以在plancache中保留的执行计划信息是很简单的，最大保存的对象其实就是stmtid产生的语法树结构（里面有大量的values值）…

tidb_prepared_plan_cache_size都设为1了，绝大多数语句都享受不到plancache了，那还不如直接关闭呢吧，这样子设置做做测试还行，实际生产毫无意义。 这个值设为1，大多数SQL语句都会进行compile，肯定会在compile啊。 所以7.1的那个参数就是解决insert大量值的情况，不让其进入plancache，正常的SQL语句可以进入plancache中来解决你这个问题的。 另外所有语句都必须生成执行计划，有了执行计划才有数据存取操作，这个所有数据库都一样的吧（只是有一些数据库没有执行计划缓存）。