【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.1
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
ticket表有自增列ticket_id作主键，还有一个唯一约束。做以下操作
create table ticket1 like ticket;
batch on ticket_id limit 10000 insert into ticket1 select * from ticket;
执行过程中一定会报错类似“1062 - Duplicate entry ‘358881-024919679577841035240089’ for key ‘ticket1.unique_ticket’”
虽然报错了，但是经过检查，所有数据都成功插入了。感觉这里有什么bug
一种可能性是数据插入期间的重复数据比较少，因此在插入时重复项被现有的唯一索引拒绝，但是另一种可能性是在某个特定点上超过了重复阈值，导致了这个错误
理论上原表和新表都是完全一样的，数据不存在重复可能性，batch on ticket_id分组插入，而ticket_id本身就是自增ID不会重复的
我用这个语句倒是没有出现Duplicate entry。
但是如果源表的表结构设置不是针对高并发写入的。源表只要有个30-40w数据量，这样导入克隆表的时候出现了热点问题。 
速度还行，比直接insert in select快 而且内存占用少，直接insert in有几百万条数据特别吃内存 limit我用10000
1 个赞
- 确保该语句不需要原子性，即允许执行结果中，一部分行被修改，而一部分行没有被修改。 → 非事务 DML 语句 | PingCAP 文档中心
- 确保该语句不会修改语句自身会读取的内容，否则后续的 batch 读到之前 batch 写入的内容，容易引起非预期的情况。
- 这个初查了下, 还是没啥已知问题, 能基于现有现有数据在测试环境模拟一份脱敏的 复现流程 出来吗? 难查🤔
就是我自己单机使用的库测试，没有并发读写也有些问题
可以把测试步骤发出来,方便大家复现
一个表，自增主键，大概有100万数据 然后create新表like原表，用batch on 主键 limit 10000 insert into 新表 select * from 原表
新表里面没有数据 原表没有变更
可能是并发的问题。
没有并发，测试库就我一个人在用
在启用 TLS 加密的 TiDB 集群中，有 3 个证书用于安全通信：
CA证书：
CA 证书 (ca.crt) 是用于签署和验证集群中其他证书的根证书。 它用于在集群的不同组件之间建立信任。 所有组件（TiDB、TiKV、PD）都需要 CA 证书来验证其他证书的真实性。
客户证书：
客户端证书（client.crt）由客户端应用程序（例如 TiDB 客户端）用于向 TiDB 集群进行自身身份验证。 当客户端连接到集群时，它会提供其客户端证书，该证书会根据 CA 证书进行验证，以确保客户端的身份。
客户端私钥：
客户端私钥（client.pem）是客户端证书对应的私钥。 它用于对消息进行签名并与 TiDB 集群建立安全连接。
在为 TiKV 和 PD 配置 cert-allowed-cn 选项时，需要指定允许连接 TiKV 和 PD 的客户端证书的 Common Name (CN)。 CN 是客户端证书中的一个字段，用于标识向其颁发证书的实体。 您可以使用应允许访问相应组件的客户端证书的 CN 值来配置 cert-allowed-cn。
例如，如果 TiKV 的客户端证书的 CN 设置为“tikv-client”，PD 的客户端证书的 CN 设置为“pd-client”，则可以按如下方式配置 cert-allowed-cn：
对于 TiKV： cert-allowed-cn = [“tikv-client”]
对于 PD：cert-allowed-cn = [“pd-client”]
这确保了只有在客户端证书中提供指定 CN 的客户端才被允许分别连接到 TiKV 和 PD 组件。
请务必根据您的实际设置和证书配置调整 CN 值和配置。
你回答错问题了
limit 10000 相当于数据切片了，就是主键切片，分组批量插入
主键是 auto_random 么？
主键是联合索引，切片的字段是自增字段，没有重复的