这个 1000 应该是没意义的，删掉和加了应该都不影响

大概率不是查不出来，只是慢，可以看看加 ddl 的时候 owner 的 cpu 啥的资源是不是满了

用 arm 呗，aws graviton

很可能是过滤条件不同导致选了不同的计划，如果一直是某个计划最优的话，可以考虑 binding

存在 tikv 的 ddl 相关的 meta 数据写坏了吧

meta 开源的

加 binding 解决，是根据查询值的统计来确定计划的，可能 cost 计算的方式不是很准确

要返回的时间点和最新的时间点之间的数据变化量，增删改有影响，但一个 key 修改多回也只算一次影响

flashback cluster 会在 tikv 的每个 region 上执行，把旧的数据读上来，然后重新用新的时间戳写下去。所以数据量越大，执行的时间就越久。统计信息相关的数据也会用被恢复的，但内存里的数据就不能保证了。

得看下执行计划

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’ 可以显示出来