把 database 慢查询完整执行计划上传一下，上面记录了详细时间消耗。

这个上面的日志，应该没多大关系。 感觉问题可能还是出在回表太高，消耗资源太大

线程类的数据库是要走到安全的埋点地方才能 kill。 进程类的数据库直接操作系统 kill 进程。像Oracle。直接是操作系统杀进程，然后 pmon 去做清理。postgresql 类似。

这两个条件 section 算子过滤后的数据是 56831，这个选择性还行。 创建 shop_id, end_time 组合索引。然后确保 shop_id 传的是数字类型。

什么版本，这个和 mysql 一样，都需要走到指定位置才可以 kill。

建议设置成off，能保持执行计划的稳定，如果设置成 on，统计信息过期后使用 10000 行来评估，容易出现执行计划走错。

tidb-server 内存长时间保持在阈 tidb_server_memory_limit * tidb_server_memory_limit_gc_trigger 值以上时，会触发 issue unexpected cpu usage caused by tidb_server_memory_gc_trigger · Issue #48741 · pingcap/tidb · GitHub 导致 CPU 长时间处于较高使用状态。 在7.5.1 版本才解决。你可以升级试试。 [image]

可以先升级 v7.5.1 试试

看上去像是这个问题 https://github.com/pingcap/tidb/issues/48741

当前什么版本 ？

TiProxy 和 TiCDC 支持的新特性 Debezium

统计信息没有过期是什么问题呢 ？ SQL发出来看看呢。

还有一个路径也可以，就是查看 performance-overview 这个面板的这个会显示Active connections [image] [image]

最直接的就是在 prometheus 中查询 tidb_server_tokens 这个表达式，只有这个表达式才代表了并发连接。 tidb_server_tokens The number of concurrent executing session TYPE tidb_server_tokens gauge tidb_server_tokens 0

这个日志出现没关系，后面显示为 dump data successfully, dumpling will exit now。这个地方是 [info]

用/*+inl_join(tt1) */ 试一下。

最最上乘的办法就是通过统计信息来解决，但是这也是最难的。 统计信息解决不了的，才分两种情况。如果是出故障的就去绑定，没有出故障的就应用自己去解决。

其实存多了不能看，还不如不存多。只存主要的。 https://github.com/pingcap/tidb-dashboard/issues/1386 [image]

这个东西不建议改，改大了会有风险。理由是，sql语句存的过多，有时候你去查，要decode 这个plan，有可能会导致数据库OOM。这个有对应的issue。就设置3000就行了，多余的本身就是不怎么活跃的，要不要无所谓。