问题是这么搞的话需要用 reorg partition 的方法来重建分区表，reorg partition 可能并没有把普通表的数据导出再导入来的效率高。

没有性能问题就可以不建啊，这个没有啥必须的。表已经用 id 建了聚簇索引，说明你的 id 就是分区列，用着没问题即可。

用 key.PrefixNextKey 找到区间的结尾，然后构造一个 iter 去遍历一遍。 比如 channel_1 的 PrefixNextKey 就是 channel_2，构造出来的区间就是 [channel_1, channel_2)

unistore 底下用的存储引擎是 badger，可能这个库在高并发下有锁竞争之类的问题？tidb 应该是没有专门做 batch 之类的操作的

先把数据导出，再重建集群导入吧。光升级是不行的。

And 也可以走 index_merge 的

不能，_tidb_rowid 的分配和 auto_id 是同一个分配机制。每个 tidb 实例会预先分配一部分作为 cache，所以可能会出现跳号的情况。

没有商业化的案例，现在只是在测试里面用到。需要单机使用 tidb 的话，为什么不用别的专门的单机数据库呢？

可能只能给 br 提个需求，让他在备份恢复完成之后 rebase 一下 auto id

没办法，除非你改成 AUTO_ID_CACHE = 1。 普通的 auto_id，你如果有两个不同的 tidb instance，两个都往一个表写，一个会是 1 开始，另一个就是 30001 开始。

怎么算自动化运维？crontab？监控 + 脚本？自动报警？自动扩容？

应该是个 bug，两者输出的类型都是 NEWDECIMAL，但 mysql 的 Max_length 是 1，tidb 的是 4 [image] [image] 在 github 上开了个 issue The result of `IF` function not compatible with MySQL. · Issue #58933 · pingcap/tidb · GitHub

不禁止啊，只是现在只有 aws 的

有太多被删掉的数据了，limit 1 就会导致并发的 rpc 只有一个，然后一个一个 region 去读，但的读到的 region 数据都被删掉了，就会一个个找下去，每个 rpc 的耗时几十毫秒，总体耗时就高了。

悲观事务，会先写到内存的 membuffer 上，并会把对应的需要锁的 key 锁上，然后在 commit 的时候把数据完整的写到 tikv 上。 可以看下 prewrite 的接口，还有悲观事务的介绍。https://docs.pingcap.com/zh/tidb/stable/pessimistic-transaction

client-go/txnkv/transaction/txn.go at a348c17c6b423ae016d80fede1b2a115a85edb5e · tikv/client-go · GitHub 悲观事务的情况下，给 tikv 对应的 key 上锁的 rpc

txn 的话 rust 也没有 batchset 吧。 按我的理解，事务模型下，set 都只是写到 membuffer 里，都是内存操作，一次写一个和多个没有啥性能上显著的区别。相对的有和 tikv 交互的 rpc，比如 lockkeys 就支持一次处理多个 key。

都有 batchPut 接口吧

有这个需求尽量用比较新的版本