诊断与解决 .NET 中因共享连接池引发的 `MySqlException: No database selected` 顽固异常

诊断与解决 .NET 中因共享连接池引发的 MySqlException: No database selected 顽固异常

问题背景

在一个基于 .NET 和 Entity Framework Core 的后台服务中，我们遇到了一个极其顽固的 MySqlConnector.MySqlException (0x80004005): errCode = 2, detailMessage = No database selected 异常。

这个后台任务的特点是：

1. 使用了多个 DbContext，分别对应不同的 MySQL 数据库。
2. 该任务被设计为定时重复执行。
3. 一个令人困惑的现象：任务总是在第一次执行时成功，但从第二次开始，必定会抛出上述异常。

这个“首次成功，后续失败”的模式是典型的“状态污染”信号，它强烈暗示着问题出在某个被复用的资源上。

探寻根源：失败的排错之旅

根据异常信息和现象，我们首先怀疑是 DbContext 的连接管理出了问题。我们进行了一系列尝试：

1. 尝试一：手动管理连接
   我们试图在每次查询前手动打开连接 (.Database.OpenConnectionAsync()) 或切换数据库 (.ChangeDatabase("..."))，但这并未奏效。DbContext 依然从池中获取了一个状态不正确的连接。

2. 尝试二：创建独立的 DbContext 实例
   我们放弃了依赖注入的 DbContext，转而在方法内部 using var tempDbContext = new MyDbContext(...) 创建一个全新的实例。令人惊讶的是，问题依旧。这让我们意识到，即使是新的 DbContext 实例，它仍然从一个全局共享的、静态的连接池中获取连接，因此还是无法避免被污染。

3. 尝试三：强制重置连接
   MySqlConnector 提供了一个连接字符串参数 ConnectionReset=true，它理论上应该在连接出池时重置其会话状态。然而，在我们的环境中，添加此参数后问题依然存在，这可能与驱动版本或服务器配置有关，但它没有成为我们的救星。

真相大白：连接池污染 (Connection Pool Pollution)

在屡次失败后，我们最终锁定了问题的根源：连接池污染。

ADO.NET 的连接池机制旨在通过复用数据库连接来提升性能。然而，当多个 DbContext 指向同一台服务器的不同数据库时，它们可能会共享同一个连接池。当一个连接被一个 DbContext（例如，ContextA，连接到Db_A）使用后归还到池中，它的会話状态（当前数据库是 Db_A）可能不会被完全重置。

当另一个 DbContext（例如，ContextB，需要连接到 Db_B）从池中获取到同一个连接对象时，这个连接仍然指向 Db_A。ContextB 基于这个错误的上下文去执行SQL查询，自然会导致 "No database selected" 或 "Table not found" 之类的错误。

最终解决方案：禁用连接池

既然问题的根源是连接池的复用机制，那么最直接的解决方案就是绕过它。通过在连接字符串中添加 Pooling=false;，我们强制 MySqlConnector 不使用连接池。

var connectionString = _thirdDbContext.Database.GetConnectionString();

// 确保以分号结尾，然后追加禁用连接池的参数
if (!connectionString.Trim().EndsWith(';'))
{
    connectionString += ";";
}
connectionString += "Pooling=false;";

optionsBuilder.UseMySql(connectionString, ServerVersion.AutoDetect(connectionString));

using var tempDbContext = new ThirdDbContext(optionsBuilder.Options);

// 使用这个临时的、拥有独立连接的 DbContext 执行查询
// ...

此举的原理是：
每次数据库操作都会创建一个全新的物理TCP连接，并在操作完成后彻底销-毁它。这确保了每次连接都是纯净的、无状态的，完全杜绝了上下文混淆的可能性。

虽然这会带来一定的性能开销（连接建立和握手的成本），但对于一个执行频率不高的后台任务而言，这种为了保证正确性和稳定性而做的牺牲是完全值得的。

结论

在 .NET 应用中使用多个 DbContext 访问同一台数据库服务器上的不同库时，必须警惕连接池污染问题。如果你遇到了“首次成功，后续失败”的 No database selected 异常，请重点排查连接池。

Pooling=false 是解决此类问题的最终手段。它虽然牺牲了部分性能，但能换来程序的稳定可靠，在很多场景下是一个非常实用的解决方案。