您是否检查了未关闭和响应的数据阅读器。在关闭连接或数据读取器之前重定向。如果在重定向之前不关闭连接，则连接将保持打开状态。

这个问题我以前遇到过。结果是防火墙出了问题。我刚在防火墙里加了条规则。我必须打开端口1433，以便SQL服务器可以连接到服务器。

在大多数情况下，连接池问题与连接泄漏有关。应用程序可能无法正确且一致地关闭数据库连接。当您保持连接打开时，它们将保持阻塞状态，直到. net垃圾回收器通过调用Finalize()方法为您关闭它们。

你要确保你真的关闭了连接。例如，如果.Open和Close之间的代码抛出异常，下面的代码将导致连接泄漏:

var connection = new SqlConnection(connectionString);

connection.Open();
// some code
connection.Close();                

正确的方法是这样的:

var connection = new SqlConnection(ConnectionString);

try
{
     connection.Open();
     someCall (connection);
}
finally
{
     connection.Close();                
}

or

using (SqlConnection connection = new SqlConnection(connectionString))
{
     connection.Open();
     someCall(connection);
}

当你的函数从一个类方法返回一个连接时，确保你在本地缓存它并调用它的Close方法。您将使用以下代码泄漏一个连接，例如:

var command = new OleDbCommand(someUpdateQuery, getConnection());

result = command.ExecuteNonQuery();
connection().Close(); 

第一次调用getConnection()返回的连接没有被关闭。这一行不会关闭连接，而是创建一个新的连接并尝试关闭它。

如果您使用SqlDataReader或OleDbDataReader，请关闭它们。尽管关闭连接本身似乎就能达到目的，但在使用数据读取器对象时，还是要花费额外的精力显式关闭它们。

这篇来自MSDN/SQL杂志的文章“为什么连接池溢出?”解释了很多细节，并建议了一些调试策略:

Run sp_who or sp_who2. These system stored procedures return information from the sysprocesses system table that shows the status of and information about all working processes. Generally, you'll see one server process ID (SPID) per connection. If you named your connection by using the Application Name argument in the connection string, your working connections will be easy to find. Use SQL Server Profiler with the SQLProfiler TSQL_Replay template to trace open connections. If you're familiar with Profiler, this method is easier than polling by using sp_who. Use the Performance Monitor to monitor the pools and connections. I discuss this method in a moment. Monitor performance counters in code. You can monitor the health of your connection pool and the number of established connections by using routines to extract the counters or by using the new .NET PerformanceCounter controls.

不要实例化sql连接太多次。打开一个或两个连接，并将它们用于接下来的所有sql操作。

似乎即使在处置连接时也会抛出异常。

在我的例子中还发生了另一个原因，因为使用async/await，导致了相同的错误消息:

系统。InvalidOperationException: '超时。从池中获取连接之前的超时时间。这可能是因为所有池连接都在使用中，且池大小已达到最大。”

只是对发生了什么(以及我是如何解决它的)的一个快速概述，希望这将在未来帮助其他人:

找出原因

这一切都发生在ASP中。NET Core 3.1 web项目与Dapper和SQL Server，但我认为它是独立于这种类型的项目。

首先，我有一个中心函数给我SQL连接:

internal async Task<DbConnection> GetConnection()
{
    var r = new SqlConnection(GetConnectionString());
    await r.OpenAsync().ConfigureAwait(false);
    return r;
}

我在几十个方法中使用这个函数，例如:

public async Task<List<EmployeeDbModel>> GetAll()
{
    await using var conn = await GetConnection();
    var sql = @"SELECT * FROM Employee";

    var result = await conn.QueryAsync<EmployeeDbModel>(sql);
    return result.ToList();
}

正如您所看到的，我使用的是没有花括号({，})的new using语句，因此连接的处理是在函数的末尾完成的。

尽管如此，我还是得到了关于池中没有更多可用连接的错误。

我开始调试我的应用程序，并让它在异常发生时停止。当它停止时，我首先看了一下调用堆栈窗口，但这只显示了System.Data中的某个位置。SqlClient，并不是真正的帮助我:

接下来，我看了看Tasks窗口，这是一个更好的帮助:

在“等待”或“计划”状态下，对我自己的GetConnection方法的调用确实有数千次。

当在任务窗口中双击这样的一行时，它通过调用堆栈窗口向我显示了我的代码中的相关位置。

这帮助我找到了这种行为的真正原因。它在下面的代码中(只是为了完整性):

[Route(nameof(LoadEmployees))]
public async Task<IActionResult> LoadEmployees(
    DataSourceLoadOptions loadOption)
{
    var data = await CentralDbRepository.EmployeeRepository.GetAll();

    var list =
        data.Select(async d =>
            {
                var values = await CentralDbRepository.EmployeeRepository.GetAllValuesForEmployee(d);
                return await d.ConvertToListItemViewModel(
                    values,
                    Config,
                    CentralDbRepository);
            })
            .ToListAsync();
    return Json(DataSourceLoader.Load(await list, loadOption));
}

在上面的控制器操作中，我首先调用EmployeeRepository.GetAll()从数据库表“Employee”中获得模型列表。

然后，对于每个返回的模型(即结果集的每一行)，我再次对employeerepository . getallvaluesforeemployee (d)进行数据库调用。

虽然这在性能方面非常糟糕，但在异步上下环境中，它的行为方式是占用连接池连接而不适当地释放它们。

解决方案

我通过在外部SQL查询的内部循环中删除SQL查询来解决这个问题。

这应该通过完全省略它来完成，或者如果需要，将它移动到外部SQL查询中的一个/多个lpe join，以便在一个SQL查询中获得数据库中的所有数据。

吸取的教训

不要在短时间内执行大量SQL查询，特别是在使用async/await时。

除了公布的解决方案。

在处理1000页遗留代码时，每个代码都多次调用公共GetRS，这里有另一种解决问题的方法:

在现有的公共DLL中，我们添加了CommandBehavior。CloseConnection选择:

static public IDataReader GetRS(String Sql)
{
    SqlConnection dbconn = new SqlConnection(DB.GetDBConn());
    dbconn.Open();
    SqlCommand cmd = new SqlCommand(Sql, dbconn);
    return cmd.ExecuteReader(CommandBehavior.CloseConnection);   
}

然后，在每个页面中，只要关闭数据读取器，连接也会自动关闭，从而防止连接泄漏。

IDataReader rs = CommonDLL.GetRS("select * from table");
while (rs.Read())
{
    // do something
}
rs.Close();   // this also closes the connection