【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
当前需要上游同步数据到tidb，使用的是replace批量更新/新增操作，但是实践过程中发现同步的效率很低，一般在10条/秒，有没什么办法可以优化呢。
调优分析下呗，没啥信息也不能帮你分析，没见过批量处理这么低的
1 个赞
看看执行计划，是慢在哪一步。存储如果是固态的，IO效率会高很多
如果使用MySQL客户端或JDBC连接TiDB，可以通过设置rewriteBatchedStatements=true 来启用异步提交，这可以减少网络往返次数，提高批量操作性能。
也可以测试下如果单纯批量的插入数据到一张新表中，看下速度是怎么样的。执行计划也看看，可以看下dashboard中的慢SQL中该SQL对应的每一步的耗时
其实我的操作很简单，用的是jdbc从上游流式同步数据，当数据量达到了2500条时，我就会将这批数据更新到Tidb，使用的是批量更新，更新语句是“replace into table (f1,f2,f3) values (?,?,?)”。不知道还有优化的空间不。另外，磁盘是用的机械硬盘。
还有就是集群Tikv、PD、TD-Server的负载都不高。
机械硬盘 本身就很慢，再加上你是批量更新，Tidb更新操作好像是insert+delete吧。
建议你在Tidb这边。把这个语句复制出来手动执行看看效果。如果相差不大，那就不是同步问题。就是服务器IOPS问题
机械盘就是很慢，没办法
不会吧，这年头还有用的机械盘做数据库么。
HDD对于使用LSM Tree作为数据存储结构的系统应该很难优化吧
从执行计划查起。
我们这边用的也是机械盘，但是没有这么慢。不过在实践中发现
这种写法
insert into table (c1,c2,c3)
values (x,x,x),
(x,x,x),
(x,x,x);
远比
insert into table (c1,c2,c3) values (x,x,x);
insert into table (c1,c2,c3) values (x,x,x);
insert into table (c1,c2,c3) values (x,x,x);
快得多。
直接看实际的执行计划吧，如果单条不慢，批量慢，就是你的资源问题
硬件问题吧
表的平均行长度很长么？ 可以单条insert多个value，一般500b左右的平均长长度的表，都建议每次insert 100~1000个value，可以验证下
我们这边实践是单条不慢，但是如果批量执行单条的，会越来越慢~
多开几个连接增大并发，而不是一个连接一次插入2500条。假如这里是2500个连接，每个replace into1条，效果和1个连接，一次2500条，效果一个天一个地。
一个是大量小事务，一个是少量的大事务。
负载利用率上不去也是为了避免大事务对资源的挤占导致小事务的延迟也升高。
还有就是批量插入的表要注意表结构的设计，避免热点。
https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices#tidb-高并发写入场景最佳实践
参考这个链接。
磁盘问题，测试下insert的同表语句速度，如果也慢，基本就是磁盘问题。如果不同，可能是因为批量的锁问题