Connection Count中的连接数浮动还是很大的，kill掉的是那类SQL ，是sleep吗

解决了没，看看相关的logfile是否定期清理

用tiup的 exec --command “sudo df -h” ，看看返回结果

NO_DECORRELATE() 提示优化器不要尝试解除指定查询块中对应子查询的关联。该 Hint 适用于包含关联列的 EXISTS、 IN、 ANY、 ALL、 SOME 和标量子查询，即关联子查询。

提前做好巡检和负载基线，遇到问题可以通过dashboard查查性能SQL， 严重的oom问题排查思路

集群的节点都是混部的，看着内存还算是比较正常

mark下

tikv_cdc_min_resolved_ts_no_change_for_1m 报警规则：changes(tikv_cdc_min_resolved_ts[1m]) < 1 and ON (instance) tikv_cdc_region_resolve_status{status="resolved"} > 0 and ON (instance) tikv_cdc_captured_region_total > 0 规则描述：TiKV CDC 模块最小的 resolved ts 1 分钟没推进。 处理方法：收集 TiKV 日志，定位原因。

坚持出海，做大做强

当然是可以source ,也这么做了。 就是想验证import into from file 这个方法，文档中提到方式。在remove changefeed 后也没有import成功 ，ERROR 1292 (22007)

重新scale-out 了cdc ，list可以看到已有的changefeed的，是可以remove掉的。 [tidb@tidb01 ~]$ tiup cdc cli changefeed list --server=http://192.168.2.72:8300 Starting component cdc: /home/tidb/.tiup/components/cdc/v8.5.2/cdc cli changefeed list --server=http://192.168.2.72:8300 [ { "id": "pingcap-01", "namespac…

开发的SQL规范有时候很重要

嗯，是可以这样搞

我也是这么理解的， 有官方文档的介绍说明吗

问题就是a表 ，为啥不选择 a.certino 列，这个字段上是有索引的。如果是这么改下执行就没问题了。 AND a.certino = b.certino AND STRCMP(IFNULL(a.payno, 1) , b.payno ) = 0

我也是疑问啊，changefeed 应该在做完测试后就已经remove掉了，就留下了cdc的节点在集群里。

如何强制删除呢，cdc 都已经scale-in了呢，我觉得已经不存在cdc相关的信息呢， chagefeed-id 的确是测试环境使用的id。

这是某一个盘出问题，还是都出问题了呢，有没有共同的地方

Lock CF 中的锁是临时状态，不会长期保留 ，任何情况下的事务完成 / 超时都会触发锁的清理； Write CF 的清理是异步、基于GC safe point版本记录机制 ，保证 MVCC 多版本读的同时，逐步清理过期垃圾数据。