@Jerin 老师，确认了下，问题现象是符合预期的：SQL命中query_watch之后action switch_group到default（action kill duration 1ms），SQL不会被kill。目前switch_group一般是针对 RU_PER_SEC 这个，降速用的 这个功能我这边已经发起了feature：select sleep(2)命中query watch后被kill，且保持duration 1m效果（此后保持一分钟之内此sql的发起一直被kill）。

本地测试了下，如上述现象。也测试了 root 默认resource group 改为rg_limit mysql> alter user root resource group rg_limit; Query OK, 0 rows affected (0.02 sec) session2 root重新连接：第二次查询生效了 mysql> select sleep(2); ±---------+ | sleep(2) | ±---------+ | 1 | ±---------+ 1 row in set (0.07 sec) mysql> select sleep(2); …

自动清理才是符合预期的

select * from information_schema.tables where tidb_table_id=‘39140’\G; 查一下

我摇个人看一下

在这个 issue 上跟进

可能是产品 bug，我本地复现了

limit 8,1 limit 9,1 回表 actrows 9 86900 回表 cop_task 7 7022 total_process_keys 9 86900 究其原因还是limit8,1 在回表之前有一层过滤

放置规则可以设置 [image] constraints ，设置每个database中表 的region的leader和follower放在同一个AZ应该，写的时候就会很快

如果表级别的放置策略不行，这个database级别的放置策略能满足你的需求吗https://docs.pingcap.com/zh/tidb/stable/placement-rules-in-sql/#为数据库指定默认的放置策略

对应机器关闭大页和 swap 就行

上面说的很清楚了啊： * 如果查询有除了全表扫以外的单索引扫描方式可以选择，优化器不会选择 index merge；

如上面所说的应该是 bug，最好是升级。 workaround ：可以找出报错的 table_id 的 table，然后 analyze 一把。如果找不到，可能是 partition_id。 或者可以滚动重启 tidb应该也可以解决这个报错。

v7.1.2 fix

learner-peer-region-count：含有 learner peer 的 Region 数量。learner peer 的来源可能是多个，例如 TiFlash 上的 learner peer，以及配置的 Placement Rules 包含 learner peer。 tiflash?

是的，确认了下，是个 bug。Root user lack rights to use `tidb_mdl_view` · Issue #53292 · pingcap/tidb · GitHub v8.1.1 fix

感觉是bug，我本地 deploy 直接复现了。

这种情况下第一时间可以看下对应 mdl 视图，看看是不是有 session 卡住了这个add index。

参考这里https://docs.pingcap.com/zh/tidb/stable/sql-statement-restore#restore