看到有用的。

感觉本质上相当于update语句吧。

分布式数据库，在单机场景，表现不佳是在预期范围内的。毕竟使用场景本身就是不一样。

没有，用过一次，只能等着。

重新定位了一下问题，不是sql语句太长的问题。 关贴了。

真是时光旅行者，都是以前未解决的问题。

可以减少，CPU内存取决于业务，如果测试，可以不用这么高。我这边一台虚拟机，跑1tidb+1tikv+1pd，只用4G内存。按文档要求的话，应该是要80G。虽然可以，但是不建议这么极限使用集群。 [image]

执行多久之后报错超时呢？我们这边遇到过 负载超时限制90s，数据库超时限制30s，应用框架超时限制60s。 当然这些限制时长都是我们这边环境的，不是所有都这样。

官方文档里已经有明确解决方案了。 https://docs.pingcap.com/zh/tidb/stable/ticdc-bidirectional-replication/#ticdc-双向复制

参照 迁移操作 执行一下试试 [image] https://docs.pingcap.com/zh/tidb/stable/tiup-cluster#迁移中控机与备份

【如果 TiDB 地区活动来到你的城市，你愿意分享自己的行业实践吗？】 我愿意当一个倾听者 【你的分享主题会是什么呢？】 无

没有更详细的内容了。再跟几天看看，如果有新的日志，再补充。

哪个参数？

用命令行执行，命令行会拆成多个单独语句分别去执行吧，不会像应用程序那样打包一个语句去执行。因为这个语句里实际是多个insert语句和update语句。

里面是N多个insert、update语句。一次发送，可以用数据库的事务，保证全部成功或者全部失败。

查了，这个是默认值。集群是从v4升级到v7.5.6的。本地集群30w长度是执行没问题。

select *的优化应该主要取决于where 条件。尽量还是不要用select *

TiCool 了

先检查有没有开启global kill吧，如果没开启，只能终止当前连接的sql，不能终止其他连接的sql https://docs.pingcap.com/zh/tidb/v6.5/sql-statement-kill/#mysql-兼容性