连接池由 sqlconnection 等自动管理，无需手动实现；连接字符串字节级一致才共享同一池，否则触发多池；必须用 using 或显式 close()/dispose() 归还连接，否则导致超时；所有池参数须写在连接字符串中。
连接池不是你“实现”的东西，而是 SqlConnection 或 MySqlConnection 自动启用的底层机制；只要连接字符串一致且没关 Pooling=false，它就在运行。
SqlConnection 连接池默认就开着，别手动 new 池对象
根本不存在 SqlConnectionPool 这个 public 类，.NET 内部用私有类型管理池，对开发者完全透明。你写 new SqlConnection(connectionString) 时，池就已经在后台准备好了——不需要初始化、不需要 Start()、也不需要注册服务。
常见错误是试图通过属性控制池大小：
-
connection.MaxPoolSize = 200;—— 这行代码不报错，但完全无效，因为MaxPoolSize是只读属性 -
Pooling=false显式关闭后，每次Open()都新建物理连接，性能断崖下跌 - 连接字符串里写
Pooling=true是冗余的（默认就是 true），但显式写出更利于排查
连接字符串必须完全一致，否则触发多个独立池
池的划分依据是连接字符串的**字节级相等**：大小写、空格、分号位置、参数顺序、甚至注释（如果有的话）都算在内。比如：
-
Database=MyDB和Initial Catalog=MyDB语义相同，但字符串不同 → 两个池 -
User Id=admin和uid=admin→ 两个池 - Windows 身份验证下，
Integrated Security=true的连接，每个 Windows 用户账号独占一个池
后果很直接：你以为设了 Max Pool Size=100，结果因字符串微小差异实际起了 5 个池，每个池上限 100，总连接数可能飙到 500，远超 SQL Server 的 max_connections 限制。
连接不 Close() / Dispose() 就等于卡死池子
这是生产环境最常导致 Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool 的原因，和池大小无关。
现象包括：
- 并发稍一上来就卡住或报错，但 SQL Server CPU、内存、会话数都很低
- SQL Server Profiler 看到大量
Login事件，却几乎没Logout - 应用重启后瞬间恢复，几分钟后又卡住
修复方式只有一条：所有 SqlConnection 必须用 using 包裹，或确保 Close() / Dispose() 被调用。注意：Dispose() 只是兜底保证 Close() 执行，真正归还池的是 Close()。
MaxPoolSize 和 Connection Timeout 参数必须写在连接字符串里
所有池行为参数只能通过连接字符串传入，例如：
"Server=localhost;Database=MyDb;Integrated Security=true;Pooling=true;Min Pool Size=0;Max Pool Size=80;Connection Timeout=30;"
关键点：
-
Min Pool Size=0更安全：设为正数（如 5）会导致应用启动时就建连接，失败会拖慢启动，且 IIS 应用池回收后这些连接失效 -
Max Pool Size别盲目调高：SQL Server 默认 100，超过需确认数据库侧是否允许（查sp_configure 'user connections'） -
Connection Timeout控制的是“获取连接”的等待时间，不是 SQL 查询执行超时；设太小（如 5 秒）容易误报，设太大（如 120 秒）会让故障响应变迟钝
真正容易被忽略的是：连接池本身没有“健康检查”机制。连接一旦因网络闪断、防火墙重置或证书过期而失效，它仍留在池里，直到下次被取出时抛异常才被剔除——这意味着首次请求失败率偏高，且错误信息往往误导人去调大池子而不是修连接可靠性。
