获取连接会消耗一些时间，在ADO.NET统计应用中，当新的请求到达时，连接会被不断地打开和关闭，ADO.NET统计高效地处理请求。在这种环境里，要求建立连接时负载很小变得很重要，ADO.NET统计并且成了系统扩展性的瓶颈。
一个解决办法就是连接池（Connection Pooling）。连接池就是在使用相同的数据源时，使会话共享的数据库连接保持持久的设置。这样可以避免总在创建和销毁连接。在ADO.NET中，连接池对于程序员是完全透明的，数据访问代码根本不需要修改。当客户通过调用Open()请求连接时，ADO.NET统计直接从可获得的池中获得服务，而不是重新创建。当客户通过调Close()或Dispose()释放连接时，也不需要丢弃连接，而是返回到池中，为下一个请求服务。
ADO.NET统计本身没有包含连接池机制。但是，多数ADO.NET提供者实现了连接池的某些形式。ADO.NET统计实现了它们自己的高效的连接池算法。这些算法在可管理代码中完全实现----这与某些流行的错误观念形成鲜明对比---不使用COM+企业服务。对于在SQL Server 和Orace中需要重用的连接来说，连接串能够精确匹配。如果稍有不同，在新的池中会创建新的连接。
提示：SQL Server和Oracle池使用纯文本算法。意思就是连接串中的任何丁点的改变都会阻碍连接池，ADO.NET统计即便是简单地更改参数的顺序或者是在***面添加一个额外的空格也不能使用连接池。它强制你在Web页中不进行硬编码连接串。相反，你应该在一个地方存放连接串（***是在web.config）文件的<connectionStrings>节中存放）。
使用SQL Server和Oracle提供者，连接池是可用的并且自动使用。然而，你也可以使用连接串参数来配置池的大小。如果使用SQL Server提供者，你可以使用SqlConnection.RetrieveStatistics()方法（.NET2.0以前没有这个方法）获得一些有趣的统计。RetrieveStatistics返回一个哈希表和不同的底层细节，来帮助你分析命令的性能和执行的任务的数量。连接统计在部署了的应用中并不会经常用到，但在测试和成型期间分析性能时很有用。例如ADO.NET统计提供了一个工具，你可以使用它来确定不同的数据访问策略执行有何不同（其它工具包括SQL Server管理工具，如SQL Profiler和Query Analyzer）。#t#
默认的情况下，连接统计被禁用以提高性能。为了使用连接统计，你需要将SqlConnection.StatisticsEnabled属性设置为true。这样就告诉了SqlConnection类收集它执行的每个动作的信息。在任何断点之后，ADO.NET统计你都可以调用RetrieveStatistics()方法来检查这个信息，或者使用ResetStatistics()来清空它，然后重新开始捕捉。
