慢查SQL来源 账号和主机异常

🪐 TiDB 技术问题
,
21

select * from information_schema.processlist where host like ‘%192.168.3.108%’; 有连接吗

22

嗯，我也觉得是个bug了，目前只能先忽略这个主机的特殊SQL

23

可能是个bug，但是从官方文档中没有看到该问题相关，这里咨询也想看看是不是只有我一个人遇到这个问题 :sob:

24

这边看到执行用户名kfzdba，这个用户是谁在用?如果可以， 尝试一下删掉这个用户，再看下

25

之前DELETE语句删表之后磁盘空间不会收缩，查了文档隔段时间会自动收缩，就是这个自动的ANALYZE吧，没有类似MySQL的 OPTIMIZE TABLE

26

这个用户是运维管理不能删除，肯定不是这个用户的问题哈，它可以从很多台主机都可以登录的，使用的’%’

27

能辛苦分享下你看到的文档么，到是之前确实删除过同名的库表，后来在做重建，但是 dm_meta 那个库就三个表，不应该在不停执行 analyze 吧

28

删除重建，名字命名不一致看下，感觉这个事件非常诡异

29

就官方文档里搜的，我那问题没你这么严重，ALALYZE造成节点慢SQL，只是简单的清理了几个亿的表，没有释放空间，当时是用的6.1
我看8.X版本文档的GC，是自己发起后，发给PD做Savepoint的

30

确实很奇怪，感觉系统把我的一次操作来源给缓存然后后续系统级别的optimize都使用了这个来源

31

目前使用的7版本也有系统行为的 auto optimize ，从对应的表可以看到，但是show processlist这个显示出来的“明显不是系统行为”，但是问题是我确认没有从这个主机上执行 optimize 操作，所以是个很奇怪的问题。

到是不影响目前的使用，就是感觉有点别扭

32

能把感觉有问题的这台服务器断网一天左右，看期间是否有相应的自动优化出现

33

还有其他的吗

34

这个网段不会有ip重复的机器了吧

35

这个确认人肯定没有的

36

其他什么？

源头就是在 慢查日志中发现的，然后show processlist 抓取到了。然后目标主机确认没有执行，然后在目标主机和tidb server tcpdump抓包都没有目标主机的该类操作，所以比较好奇是怎么来的

37

难道这个还有潜伏期吗？

38

你们是不是有人连上去执行 Analyze：

image
image1022×56 11.1 KB

这用户名看起来是某一个 dba 的账户。

39

哈哈哈，好一个潜伏期 :joy:

40

嗯是内部一个dba账号，但是当时确认没有人执行，因为tcpdump抓包没有抓到数据，但是tidb测试依然有analyze 请求操作