应该是有几个类似的 bug 需要注意：
一个是楼上提到的这个 Duplicate entry when using BR to restore a NONCLUSTERED AUTO_ID_CACHE=1 table · Issue #46093 · pingcap/tidb · GitHub
- nonclustered 表的话会有一个 auto increment 的隐藏列 _tidb_rowid，当 nonclustered 表同时存在auto_id_cache=1 的 auto increment 列的情况下，lightning/br 导入后，会丢失 _tidb_rowid 的一部分metadata(auto_increment的具体值)。
- 经过 lighting/br 导入后，表中用户定义的自增列和 _tidb_rowid 的 metadata 混在一起，造成两个在show table 里观察到的值都不正确。同时因为 metadata 不正确，所以无法正确发号，会造成 duplicate entry 的 error。
还有一个是 DDL lost history jobs after batch creating tables · Issue #43725 · pingcap/tidb · GitHub
- 当 BR restore 执行 batch create table 遇到 “entry too large, split batch create table” 报错时导致部分表创建失败，后续 BR 在 split batch 重试 batch create table 时发现这些表已经存在就直接返回错误了，不会走到后续更新 auto id 的逻辑，最后重新分配 auto id 会出现主键冲突的现象。
- TiDB 日志中出现执行 “create tables” 时报 ErrEntryTooLarge 错误。检查 admin show ddl jobs，某个建表 DDL job 被 cancel，但实际上执行成功（比如能通过 show create table 获取到表信息）。
升级是比较好的处理方式，不然 workaround 可能就是 alter table auto_increment = x 手动重置 auto id