[Bug]: Routine leaks after long runs

[nnsgmsone]

Is there an existing issue for the same bug?

• I have checked the existing issues.

Environment

- Version or commit-id (e.g. v0.1.0 or 8b23a93): dd43a976f540229eefba47d5a8f83722db1b729c
- Hardware parameters:
- OS type:
- Others:
稳定性测试的机器

Actual Behavior

在稳定性测试的机器上运行mo时间超过一天后，goroutine的数目会从几百飙升到几千，这些goroutine会附带的导致大量的资源泄露。目前这是在cache重构后的分支上，长时间运行遇到的一个比较严重的阻碍长时间运行的一个问题。

Expected Behavior

No response

Steps to Reproduce

No response

Additional information

No response

[nnsgmsone]

正在定位和处理中。

[nnsgmsone]

@gavinyue 麻烦gavinyue修复一下大量的sql goroutine泄漏的问题。。具体原因已经告知了gavinyue了。

[nnsgmsone]

https://github.com/matrixorigin/MO-Cloud/issues/1792，关联issue

[gavinyue]

#12899

这个PR 给connection加了timeout, 应该解决了db connection泄露的问题

[xzxiong]

@gavinyue

此处的goroutine 有明显的泄露。（感谢 @daviszhen 指出问题）

goroutine-full.txt 有数千个以下的goroutine

goroutine 2669528 [select, 6733 minutes]:
github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1()
    /go/pkg/mod/github.com/go-sql-driver/mysql@v1.7.1/connection.go:614 +0xaa
created by github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher
    /go/pkg/mod/github.com/go-sql-driver/mysql@v1.7.1/connection.go:611 +0x10a

应该是使用的问题：
dbConn 本身就是连接池，全局统一管理更合理。

[daviszhen]

watcher 的关闭的方式：
1，调用close方法。

2，用带ctx的函数。PingContext,ExecContext,QueryContext，PrepareContext等。

当ctx被各种原因cancel时，watcher也会退出

[gavinyue]

Working on it

[xzxiong]

@gavinyue

此处的goroutine 有明显的泄露。（感谢 @daviszhen 指出问题）

goroutine-full.txt 有数千个以下的goroutine

goroutine 2669528 [select, 6733 minutes]:
github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1()
    /go/pkg/mod/github.com/go-sql-driver/mysql@v1.7.1/connection.go:614 +0xaa
created by github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher
    /go/pkg/mod/github.com/go-sql-driver/mysql@v1.7.1/connection.go:611 +0x10a

应该是使用的问题：
dbConn 本身就是连接池，全局统一管理更合理。
...

已经是全局管理了。
所以问题，还是出在 Close 没有正常调用，导致连接没有释放。

[gavinyue]

#13122

[gavinyue]

@nnsgmsone please take a look and close.