计划不是一样的么，都是 indexLookUp，dashboard 多了一个 estCost，这个用 explain format=‘verbose’ 可以显示出来

是的，对外只有一个 sql 的接口，可以把 tidb 看成一个整体，内部的组件有 tidb-server、tikv-server 和 pd-server。 注意不要在同一个 tikv-server 的集群里混用 txn kv 和 raw kv，会有一些潜在的问题

tikv 就是单纯的 kv 存储，tidb 的话再上面包了一层 sql 的实现。 如果你想用的方便易用角度来看的话，肯定是 sql 比较方便，能支持的接口和功能更丰富。 kv 的好处就是简单，然后裸 kv 的性能也会更好。

https://github.com/pingcap/tidb/issues/52711 感觉是这个问题

指 order by 之后的相同值的结果顺序稳定么？这个做不到的，单表都不能保证

试试 tiflash

collation 的关系，show collation 里面可以看到 Pad_attribute，选 NO PAD 的 collation 就不会报错了

隔一段时间抓一个内存的火焰图，对比下哪部分内存涨的比较高

代码里调用一下 log.SetLevel(zapcore.ErrorLevel)

问题是这么搞的话需要用 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 开始。