mysql同步没有这个问题，业务反馈这个是归档库，数据只会从mysql过来，不过我们确认日志来源的sql 确认一下

CREATE TABLE user_bind ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT, game_id int(11) unsigned NOT NULL, user_id bigint(20) NOT NULL, mobile_num varchar(50) NOT NULL, ext_info json NOT NULL, create_time datetime NOT NULL, update_time datetime NOT NULL COMMENT ‘’, db_updated datetime DEFAU…

上传了

tidb.log.gz (5.5 MB) tidbslow.log.gz (29.6 MB)

[image] 发现这个表是0条数据 统计信息也没有问题（也重新收集了）从processlist 看 还是很慢

新加的机器 同时有五台，五台都出现这种情况，新加的机器类型跟之前的也是一样的 ，节点都在一个机房机柜里

[image] 目前都是还是这样 不合理的 持续几个小时了

看了对应节点慢的sql 也都是走的point get [image] 然后时间耗时看不出是哪里耗时

而且只有新加的tidb-server节点有问题，应该跟统计信息也没啥关系？如果跟统计信息有关系，应该是所有tidb-server节点？

这个当时看过 手动执行sql 是没有问题的，看都能走索引

忘了说么了哈， 1.重新加入节点之后，业务是有重新reload的哈，而且连接也均衡的 2.新加几个节点qps上不去看着是因为慢查询非常多，导致上不去

版本已经是5.7.6了 刚才看了一下 应该是虚拟列的问题 additional_tag json DEFAULT NULL COMMENT ‘附加标签项’, tag_100004 tinyint(4) GENERATED ALWAYS AS (coalesce(json_contains(additional_tag, _utf8’“100004”'), 0)) VIRTUAL, 在7.5.4没有问题 到7.5.6就有问题了 建一个表包含这两列，然后插入数据后 执行 analyze table 就会报错 runtime error: index out of range [22] w…

当时所有表都analyze过了 只是analyze是一个比较长的过程，这个过程中对业务还是有影响

analyze之后就正常了

整个过程中，升级tikv也没有问题，看起来是升级tidb-server之后开始有问题 怀疑是tidb server没有加载到统计信息 从升级过程中的日志来看 tidb server成功加载了 schema [image] 但是stats 看着是加载失败了 [image] 还有一个这个错误 [handle_hist.go:125] [“SyncWaitStatsLoad meets error”] [errors="["sync load took too long to return","sync load took too long to return","sync loa…

业务插入是 开启general 日志 从日志记录来看 是正常json [image] 但是业务查询 还是显示为base64格式的

起来的时候检查过日志 看起来是能正常的 [image]

升级到7.5.5确实不会被卡住了，进程也正常起来了