1 这个问题是 sql 本身写的有问题吧，或者时间计算的不对。你分表之后，如果不能准确的定位到某少数表的话，还是需要每个表都查询加数据整合，只是把时间和逻辑从数据库移到了应用而已 2 这个有啥风险呀？从理论上来讲不应该存在这个问题 3 这个用了新的 ingest 模式加索引能快很多，但对磁盘的空间有要求。而且分表还是那个问题，加索引还是要对每张分的表都做一遍的。

分布式数据库和单机数据库在数据量小的情况下有性能差距很正常，分布式数据库的优势在可扩展性和大数据量下的表现

大概率是系统整体慢了，网络、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 就是分区列，用着没问题即可。