【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
现从dashboard中慢查询中查询到 replace info，，，，有非常多的慢SQL，总执行时间都超过30 s ,最大内存900kib -2MiB区间，查看SQL应该都是批量inset插入数据，请问下像这样的情况有什么好的优化方式？ 是把批量SQL改成单条SQL，或者减少每次SQL的内存大小？
先看下对应的表有写热点没有
然后看下jdbc连接上
useServerPrepStmts和cachePrepStmts
设置成true了吗
注意 prepStmtCacheSqlLimit和 prepStmtCacheSize这个也要设置大一点，不然光上面俩值设置为true也不好使
使用了 batch吗？没用用上，
用了记得设置 rewriteBatchedStatements = true
这个我得看下代码，刚过来，不知道代码中是怎么配置的
看下Dashboard里面显示的慢是慢在什么阶段
先定位一下慢的原因，然后根据原因再进行针对性的优化方案。
现在不确定导致慢的地方在哪里，其他人提的优化措施可能都不一定是合适你的业务场景的
可以试下改单条，有些时候，过将批量插入的 SQL 改为逐条插入，可以减少事务锁定时间，提高并发性能
我单纯的有个疑问，批量插入是慢sql很正常。是插入慢影响使用了，还是有要求需要缩短插入时间？
另外，感觉replace into有性能问题吧，为什么不直接insert into？
主要是为了去重数据
可以将写入数据和去重分成二步来做
您的意思是，先全量插入，再用另一个服务去重？ 或者在数据插入完，再去去重？
主要慢在replace into 批量入库的锁表和事物耗时比较长
我知道是为了去重，我的意思是为什么会有重复数据，是否可以在插入之前将重复数据过滤掉。这样全量推给数据库，只不过是性能瓶颈转移了，并没有解决实际问题。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。