C# MySQLConnector不断达到最大连接数（共4个）

我在Azure上使用ClearDB，总共有4个可用连接ASP.NET Core 1.1
另外，我正在使用Ngrok公开运行API的本地主机。
当我发出同步请求时，我的API有时使用相同的连接，但在短时间内创建一个新的连接，使旧的连接处于休眠状态。
它们需要很长时间才能消失，我最终得到了同一用户使用相同的远程主机IP建立的4个连接，但每个连接都有一个不同的端口。
根据ClearDB门户，它们不被使用，并且具有等同于“睡眠”的命令。
我认为Ngrok可能是问题的根源。但是，当我尝试调用

MySqlConnection.ClearPool（Connection）我的API请求永远不会完成，他们只是永远停留在那个命令上。

在每个请求结束时，我还会调用
Close
和
Dispose
。

有什么想法吗

function1() {
    Connection.Open();

    var Cmd = Connection.CreateCommand() as MySqlCommand;
    Cmd.CommandText = "SELECT * FROM users WHERE senderID=@SenderID";
    Cmd.Parameters.AddWithValue("@SenderID", UserData.SenderID);
    var result = Cmd.ExecuteReader();
    if(result.HasRows) {
        result.Read();
    }
    Cmd.Connection.Close();
    Cmd.Dispose();
    result.Dispose();
}

public bool DoesUserExist() {
    var Cmd = Connection.CreateCommand() as MySqlCommand;
    Cmd.CommandText = "SELECT senderID FROM users WHERE senderID=@SenderID";
    Cmd.Parameters.AddWithValue("@SenderID", UserData.SenderID);
    var result = Cmd.ExecuteReader();
    bool UserExisits = result.HasRows;
    Cmd.Connection.Close();
    Cmd.Dispose();
    result.Dispose();
    return UserExisits;
}

function2() {
    var Cmd = Connection.CreateCommand() as MySqlCommand;
    long Time = DateTimeOffset.Now.ToUnixTimeSeconds();

    if(DoesUserExist()) {
        Cmd.CommandText = "UPDATE users SET lastcontact=@time, contextS=@contextS WHERE senderID=@SenderID";
    } else {
        Cmd.CommandText = "INSERT INTO users(senderID, contextS, lastcontact) VALUES (@SenderID, @contextS, @time)";
    } 
    Cmd.Parameters.AddWithValue("@contextS", UserData.Context);
    Cmd.Parameters.AddWithValue("@time", Time);
    Cmd.Parameters.AddWithValue("@SenderID", UserData.SenderID);
    Cmd.ExecuteNonQuery();
    Cmd.Connection.Close();
    Cmd.Dispose();

    Connection.Close();
    Connection.Dispose();
}

您的连接是否使用

块包装在

中？这通常比手动调用
Close
和
Dispose
更可靠，并且应确保连接正确终止。它可能无法解决问题，但可能会缩小范围。当连接超时时，是否捕捉到异常？堆栈跟踪在这里可能很有用。我得到的唯一例外是已达到最大连接数。没有超时异常。我将尝试使用块并返回报告。关于依赖性，顺便说一句，我也使用了作用域。但它似乎没有做任何值得注意的事情。超时异常中是否嵌套了内部异常？这让我很惊讶。。。。我怀疑NGrok在这里引起了问题。我以前从未使用过它，但在过去用于SQL请求的IPSEC隧道上确实存在超时问题。我们的解决方案是提高连接限制并定期回收陈旧的隧道。@Alex:使用比调用
.Dispose（）
有什么不同<代码>使用

语句/块是

var object=someObject的包装器；try{…}最后{object？.Dispose（）}

@Tseng手动调用

Dispose

可以在

try…catch

块中创建对象。如果您坚持使用块执行

，则始终会出现
try…catch
。