Entity Framework默认是否复用ADO.NET 100连接池中的数据库连接？

不能直接绝对认定Entity Framework（以下简称EF）的所有读写查询都会复用ADO.NET连接池中的可用连接，该结论仅在符合默认使用规范的前提下成立，同时存在多种明确的例外场景。

EF（包含传统EF6、跨平台EF Core）底层确实基于ADO.NET实现，数据库连接的创建、释放、复用逻辑完全由项目引用的ADO.NET数据库驱动负责：

• 若使用官方SQL Server等原生支持连接池的驱动，且连接字符串未做特殊修改，ADO.NET会为每个唯一的连接字符串维护独立的连接池，单池默认最大容量为100。
• 默认使用规范下，EF会全自动管理连接生命周期：查询执行前按需打开连接，查询执行完成后立刻将连接释放回连接池，后续新查询发起时会优先从池中获取空闲连接复用，避免反复建立TCP物理连接带来的性能开销，这也是连接池机制设计的核心目标。

以下情况中EF查询不会复用连接池中的可用连接：

• 显式关闭连接池：如果在连接字符串中配置了Pooling=false，ADO.NET会直接停用连接池机制，每次查询都会新建全新的物理连接，执行完成后直接销毁，完全不存在复用逻辑。
• 池内无可用空闲连接：如果连接池中的连接全部被长时间占用、未及时归还，新查询发起时没有可复用的空闲连接：此时若池容量未满会新建物理连接填充入池，若已达容量上限则会等待连接释放，等待超时后直接抛出连接异常。
• 手动违规管理连接：如果开发者手动创建数据库连接实例赋值给DbContext，且未按规范及时释放连接，会导致连接无法按时返回连接池，不仅其他查询无法复用该连接，长期积累还会耗尽连接池容量触发故障。
• 驱动不支持连接池：部分小众数据库的第三方ADO.NET驱动未实现连接池逻辑，自然不存在池内连接复用的能力。

实操提示：绝大多数常规业务开发场景中，只要不手动修改连接池默认配置、不越权手动管理EF的数据库连接生命周期，EF的读写查询都会按预期复用ADO.NET连接池中的可用连接，不需要额外做特殊配置。

内容的提问来源于stack exchange，提问作者variable