【 TiDB 使用环境】线上
【 TiDB 版本】TiDB v5.2.1
【遇到的问题】
goroutine泄漏，goroutine数量会飙升，升到一定程度OOM重启，这种情况会反复出现。
【问题现象及影响】
TiDB日志
goroutine 104283480 [chan receive, 124 minutes]: github.com/pingcap/tidb/executor.(*AnalyzeColumnsExec).subMergeWorker(0xc121284900, 0xc05e51eae0, 0xc05e51eb40, 0x17, 0x1) /home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/analyze.go:1201 +0x4e5 created by github.com/pingcap/tidb/executor.(*AnalyzeColumnsExec).buildSamplingStats /home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/analyze.go:849 +0x68b goroutine 96834476 [chan receive, 147 minutes]: github.com/pingcap/tidb/executor.(*AnalyzeColumnsExec).subMergeWorker(0xc0af5757a0, 0xc0ca34ab40, 0xc0ca34b1a0, 0x17, 0x1) /home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/analyze.go:1201 +0x4e5 created by github.com/pingcap/tidb/executor.(*AnalyzeColumnsExec).buildSamplingStats /home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/analyze.go:849 +0x68b
7月26号开始，那天加了新的业务，导致会多一些数据的写入，但是qps不算特别高。
xfworld
(魔幻之翼)
4
是大事务导致的么？ 我建议通盘查下 各个节点的相关的指标
tidb OOM，无外乎：
- batch insert
- Query SQL 的算子下推不支持，需要聚合后在做处理
- batch update
是否还有其他的 tidb 的服务节点，也有类似的问题？
是存在qps约为2k-3k左右的batch insert/update操作，只能降低并发处理吗？查了下日志Top 10 SQL中mem_max大概在60-70k左右。我再查查其他节点的。
补充：goroutine暴涨会在不同节点轮流交替暴涨直到OOM
xfworld
(魔幻之翼)
8
并发不用降低阿，看起来不是这个问题，如果事务很大的话，拆小就可以了，等于是把长事务拆成很多小事务来执行了，如果业务逻辑上允许的话。
然后 集群有定义 auto Analyze 的功能么？
有Auto Analyze功能，但是都在报错，报错信息都类似如下：
[2022/08/03 08:31:27.862 +00:00] [ERROR] [update.go:1085] ["[stats] auto analyze failed"] [sql=“analyze table %n.%nindex %n”] [cost_time=4.24714ms] [error=“other error: invalid data type: Failed to decode row v2 data as u64”]
xfworld
(魔幻之翼)
10
那建议先关掉 Auto Analyze功能 ，这个对 读写都会有影响
关掉后，你可以检查下表的健康度，对于表健康度比较差的，可以手动 analyze，选择业务不繁忙的时候执行。
invalid data type: Failed to decode row v2 data as u64
这个错误好像是解码的问题… 有点怪
感觉是这个问题了，我去提一个feature request吧。复现路径是把原有的表某列数据类型改了，那列之前存在有索引，改了表中那列的数据类型但是没有改索引的。于是auto analyze数据类型转换一直报错。
feature request是modify column的时候直接把索引的数据类型也改了。
xfworld
(魔幻之翼)
13
DDL 修改了索引列的数据类型，导致原来的索引值没有被清理 ，以及回填么？
最好收集下操作的场景，，如果能复现的话，肯定是bug了 
麻烦看下 tidb_analyze_version 的值
我这边在6.1版本做了复现，并未复现，请问你是什么类型修改到什么类型。
我想用macbook复现也并未成功，现在手动执行analyze table也并未出现生产环境中出现的类型错误。
tiup playground v5.2.1 --db 2 --pd 3 --kv 3
当时是从varchar(256) null 改到bigint unsigned null。
有没有可能是变更过程出问题了（连接丢失之类），导致索引文件的schema存在2个不同的版本？
修改列的数据类型并不是用事务的。改字段类型时间太长了，可能中途有问题，没有全部完成更改。
