【 TiDB 使用环境】测试
【 TiDB 版本】6.1.0
【复现路径】使用JDBC向单表插入数据，比较单connection和多connection插入性能
【遇到的问题】
单connection插入时，速度约5k/s；3 connection同时插入时，速度约1.5w/s；增加更多连接后，总体速度不再增加，单个连接速度减慢。目前设置innodb_thread_concurrency=0，请问tidb或kv是否有参数可能影响这种场景下的插入性能?
目前测试时已经在使用batch update，
那就看看集群压力：
- 有没有热点
- 每个组件的 cpu、内存使用率
- tikv 的 io 是否已经是瓶颈
两种情况使用的是一样的测试数据，有热点问题，但应该不是变量。
多connection插入时tidb和tikv组件cpu使用率均比单connection时更高。
鉴于多connection插入时总体速度要更快，是否可以不用考虑tikv io瓶颈？
我是否可以认为机制上单连接和多链接在单表插入性能上应该无太大区别？
3个链接就打满了？
如果更多链接没有增加总的吞吐量，那就得看看是tidb的cpu满了还是tikv的cpu满了，然后对应的扩容或者平衡热点。
不好意思我可能没描述清，就是这个是一次性插入大量数据的场景，我在测试时发现单链接插入的性能不好后，尝试多链接同时插入，发现速度总体上（加起来）提升了很多，于是就想知道是否单链接的插入效率有某种限制，因为我们之前使用oracle时，即时使用多连接来插入，速度加起来也只是和单连接基本持平，而这个速度远快于当前我们测试时tidb单连接的速度
那是肯定的，举例子，单个链接，单次查询的延迟是10毫秒，那qps顶多就是100，因为是串行的。
但是并不意味着tidb就不能处理更多了。tidb还有更多的cpu可以处理更多的请求，因为tidb是分布式数据库，每一次查询都得网络交互很多次，所以延迟比较高。
但是在等待网络io的同时，tidb、tikv节点的cpu还闲着呢，这时候可以处理其他的请求。所以连接数越多性能越好，直到cpu打满。
我刚才发现，即使使用了preparedStmt、batchUpdate和rewriteBatchedStatements （size大概2000-10000）这个插入sql在执行时还是需要大量时间来parse和compile，甚至占用了总耗时的大半（第一行2000一组，第二行10000一组）
parse 是解析sql，如果一次发送的value很多，解析时间长一些。
compile 是查询优化的时间。
遇到过batch size太大，改小可以走plancache的问题。
1 个赞
可以参考一下官方的一个优化实践，里边的参数设置是通用的，可以大幅度减少无用的SQL数量
https://docs.pingcap.com/zh/tidb/stable/performance-tuning-practices
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。