结果差了很多啊，第一个计划 join 的结果有快 100w 行了，第二个才 8 行。
计划不是一样的么，都是 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 的性能也会更好。
指 order by 之后的相同值的结果顺序稳定么？这个做不到的，单表都不能保证
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 之类的操作的
不能，_tidb_rowid 的分配和 auto_id 是同一个分配机制。每个 tidb 实例会预先分配一部分作为 cache，所以可能会出现跳号的情况。
没有商业化的案例，现在只是在测试里面用到。需要单机使用 tidb 的话，为什么不用别的专门的单机数据库呢？
