如果觉得是 tidb-server 侧的问题： 看下 proxy 侧有没有瓶颈 看下应用服务器资源使用率 有个通用优化方案是 tidb-server 多实例部署并且绑核或者绑 numa。会有提升的。

改了 好了？

如果是 truncate table，gc 后会立马回收空间的。 alter table compact 是压 tiflash 的，和 tikv 无关。

我看了下内部 release 计划，8.5.4 才能修复。 TiKV assertion panic related to CDC · Issue #18498 · tikv/tikv · GitHub 这个问题

我看了下内部 release 计划，8.5.4 才能修复。 TiKV assertion panic related to CDC · Issue #18498 · tikv/tikv · GitHub 这个问题

[image] 对应的 cpu 线程有太大么？看起来已经超过默认限制了。

可以一样场景在 MySQL 上测试下，对比下行为反馈下。如果不一样就去 bug 区反馈下即可。

看起来这个项目已经没更新了。

官网提供了：scrape 部分自定义，能满足你的需求么？ https://docs.pingcap.com/zh/tidb/stable/customized-montior-in-tiup-environment/#自定义-prometheus-scrape-配置 主要你想干啥？

[image] 去看下监控，这个地方每次高的都是一台还是多台。

看下监控，tikv detail >> error 下面的监控面板有什么。

新版本 join 是 hash join。 Index Hash Join（哈希连接）是先将外表结果全部读出，构建哈希表，然后用内表去 probe 哈希表。 适合JOIN 字段有索引，且能把一侧数据放入内存场景。在大数据量时通常比嵌套循环连接快，join 的顺序不受外表顺序制约。需要消耗更多的内存来构建哈希表，结果顺序通常不保证。 会快一些 低版本 index join 造成了看似排序的结果。 但是SQL 标准里，除非显式加 ORDER BY，否则结果集的返回顺序是不确定的（无排序预期) 所以结果不排序是预期的。

发下两个执行计划，你看看是不是低版本的 order by 或者什么并发为 1

你子查询排序和 sql 结果排序无关。

改 SQL 吧，如果需要排序的话，本身 SQL 就少写了排序。 之前能排序估计也是执行计划的原因。

你这个需要再最外面加个排序，你这个 sql 语义也没有排序的含义吧。

拿下这两个 SQL 结果提供下： explain analyze SELECT /*+ use_index(trade_order_seller, idx_seller_id_create_time_us) */ id, order_no, sub_order_no, biz_type, biz_channel, biz_code, biz_id, abs(sub_order_status) AS sub_order_status, buyer_id, buyer_name, seller_id, seller_name, pay_amou…

可以先加个 set var hint 解决： /*+ SET_VAR(tidb_opt_ordering_index_selectivity_threshold=0),use_index(trade_order_seller,idx_seller_id_create_time_us) */

预估 4 应该是 limit 4 导致的。应该和统计信息无关。 实际扫那么多数据，应该是索引过滤出来的数据，还有其他非索引字段过滤条件，很多不符合，因此在不断地排序往下找。所以就慢了。 如果很快能找到，实际上第二个执行计划是快的，麻烦的是他往下找的深度太深了就会很慢了。