TiKV 是一个支持事务的分布式键值数据库，而 TiDB 是基于 TiKV 构建的分布式关系性数据库，SQL 语法高度兼容 MySQL，你看你业务需要什么

因为低版本 jdbc 客户端的 bug ，会往服务端发送错误的语句，可以设置 allowMultiQueries=true 测试下，参考: https://bugs.mysql.com/bug.php?id=96623

提供下 jdbc 版本信息

测试下 ssh 到目标机器，再看下目标机器的日志

强制走索引看下评估成本就好了，看情况应该是单列索引选择度不够高

raw kv 写入吗？可以通过 pd 获取 region 相关信息，看 region 范围判断写入位置

你都不知道是干嘛的，你装它干啥？

这可不是两种写法，而是两种不同的组件，kvcdc 是给 raw kv 用的同步工具，你要是普通集群就用 cdc_servers 这个就好了

tidb 中 ddl 是 online ddl ，又不需要加锁

这种情况锁定统计信息就好了，参数设置来设置去的比较麻烦

region_id 是 region 的 id leader_id 是处于 leader 角色的 peer 的 id 对基础概念不懂可以多看看 tidb 的视频，讲的很清楚

默认按表力度分，一个表由一个 processor 处理，往 kafka 发的时候可以设置成按 region， 参考：https://docs.pingcap.com/zh/tidb/stable/ticdc-changefeed-config/#scheduler

看下元数据锁情况，https://docs.pingcap.com/zh/tidb/stable/metadata-lock/#元数据锁

不会，TiDB 是行级别锁

那这个时间长就是一直在重试，重试到超时失败了啊

raft-io 这里看着还行， commit 重试等待时间比较长，你看下这个 sql 是执行成功还是失败的

redo log，undo log ，write-ahead log ，你就删吧，一删一个不吱声

不同组件中间是有网络的啊，你怎么知道你的 txn-1 一定比 txn-2 先到 tikv 呢？

region 是 TiDB 中的逻辑概念，是一段左闭右开范围的 kv 数据，insert 时根据编码出的 key 判断要插入到哪个 region，region 的多副本通过 raft 协议保证一致性，当多副本宕机时，region 无法提供读写，所以插入会失败（因为它根据 key 算出来必须要插入到这里，这个 region 又不可用）