count 和 sum 得看执行计划，计数和去重肯定还是有区别的。 实际上还是扫那么多数据肯定要消耗的。压缩应该只是减少了 io。 不过我也觉得 tiflash 本身肯定还是有一些优化空间的。

不过 cpu 够的话，一亿多的列扫 4s 确实不算快。

他只是会同列数据进行高压缩存储，但不会自动合并相同值的记录，原始数据的行级信息仍被保留。 也就是 TiFlash 中该字段的存储仍会保留所有行的记录，所以你看他这个执行计划还是扫了很多数据的。所以 cpu 使用高也就是 ru 高了。。。。

30ms 和 16ms 区别差异在这看个啥。

为啥只扫 16 条？

给个 plan replayer 我看看。

而且对比两个索引 hint 确实发现性能差距很大？别迷信“字段多的复合索引更好”哦。。。。

用 hint 控制走的索引，看下预估和 cost。 感觉是 order by 排序 + limit 比较小，导致优化器认为排序加分页 top 优化会更快导致走 B。

去掉条件肯定不走啊，中间缺两列为啥要走 A。

tiflash 扫整列的，扫了 1 亿多数据，资源消耗高也正常。 https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md

应该没有。 不过你如果是多个库备份，可以启动多个 br 备份不同库。拆任务吧。

sub_order_status != 1000 OR biz_type != 21 这个看起来会导致 A 索引失效，就算走了应该也是走 seller_id 列过滤。 你可以用 hint 走 A 索引后，看看执行计划里面的过滤列覆盖度。

https://docs.pingcap.com/zh/tidb/v7.5/system-variables/#tidb_opt_ordering_index_selectivity_threshold-从-v700-版本开始引入 试试这个参数能解决问题不。

处理 OK 了？

下次可以看看

假的统计信息，你去看对应的直方图什么的应该没有。

BR 还原后，要手动收集下统计信息。哪里看到的客户恢复统计信息？

来一份 plan replayer

问题解决了么？ 没有任何提供的话，可能会被判定为刷分。