sqlconnection默认启用连接池（pooling=true），无需手动开启；但必须用using或显式close/dispose归还连接，且连接字符串差异会导致独立池。
默认就开了，不用手动启用；但不关它，它就会一直占着连接资源，直到程序退出或连接超时被回收。
SqlConnection 默认开启连接池，Pooling=true 是隐式默认值
只要你用的是 SqlConnection（SQL Server），连接池在底层自动启用，不需要额外代码。它的开关由连接字符串里的 Pooling 参数控制：
- 不写
Pooling→ 默认为true - 显式写
Pooling=false→ 彻底禁用池，每次Open()都新建物理连接 -
Pooling=true时，即使调用了Close()或Dispose()，连接也不会真正断开，而是归还到池中等待复用
注意：OleDbConnection、OdbcConnection、OracleConnection 的池行为也由各自提供程序决定，但逻辑类似；而 MySqlConnection（MySQL Connector/NET）同样默认启用池，且参数名一致。
关键连接字符串参数：MinPoolSize、MaxPoolSize、Connection Timeout
这些参数直接影响池的“弹性”和稳定性，不是设了就完事，得结合实际负载调：
-
MinPoolSize=5：应用启动后，池里至少维持 5 个空闲连接。避免冷启动时首次请求慢，但会提前占用 DB 连接数 -
MaxPoolSize=100（默认 100）：池最多容纳 100 个连接。超过后新请求会阻塞，直到有连接释放或超时抛出TimeoutException -
Connection Timeout=30（默认 15 秒）：当池满且无空闲连接时，请求最多等 30 秒；超时后报错A network-related or instance-specific error occurred...
常见误配：把 MinPoolSize 设得过高（如 50），但 DB 服务器最大连接数才 200，多个服务一跑就抢光资源；或者 MaxPoolSize 过低（如 10），高并发下大量请求排队卡死。
必须用 using 或显式 Close()，否则连接永不归还
这是最常踩的坑：不释放连接，等于从池里借走却不还，池会慢慢“失血”。哪怕只漏掉一个没关的连接，在高频场景下几小时就能耗尽整个池。
- 推荐写法：
using (var conn = new SqlConnection(connectionString)) { conn.Open(); // 执行操作 } // 自动调用 Dispose() → 归还连接到池 - 错误写法：
var conn = new SqlConnection(connectionString); conn.Open(); // 忘记 conn.Close() 或 using 包裹
→ 连接长期占用，最终触发TimeoutException或 DB 拒绝新连接 - 注意：
Close()和Dispose()对SqlConnection效果等价，都只是归还，不是销毁
连接字符串不同 = 完全不同的连接池
连接池是按**完整连接字符串内容**做哈希匹配的。哪怕只差一个空格、一个分号、大小写不同，都会创建独立池：
-
"Server=A;Database=test;Pooling=true;"和"server=a;database=test;pooling=true;"→ 两个池 -
"...User ID=sa;"和"...UID=sa;"→ 两个池（因为 SQL Server 认为它们是不同凭据） -
"...Initial Catalog=db1;"和"...Initial Catalog=db2;"→ 两个池
后果很直接：你本想复用连接，结果却在多个小池之间来回创建销毁，完全失去池的意义。微服务或配置中心环境下，尤其要注意连接字符串拼接逻辑是否引入了不可见差异。
真正难的不是“怎么开池”，而是判断什么时候该调小 MinPoolSize、什么时候该拆分连接字符串、以及如何监控池中连接的实际使用率——这些没法靠文档解决，得看 sys.dm_exec_sessions 或性能计数器里的 NumberOfPooledConnections。
