大概率是系统整体慢了，网络、io 之类的都有可能

这不是收集统计信息，这是查询统计信息。慢的话可以看下具体的执行信息，分析下

可以试试在最终要跑的机器上编译，编译前加上 export RUSTFLAGS=“-C target_cpu=native”，但不确定 tikv 静态依赖的库里面有没有用到这些指令

cat /proc/cpuinfo 里面可以看下支不支持 pclmulqdq，不支持的话 panic 是符合预期的。得重新编译个 tikv 才能运行。

数据多了，慢也是正常的呀

结果差了很多啊，第一个计划 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 的性能也会更好。

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 之类的操作的