一、能否通过会话ID从DMV获取连接字符串？ #

直接说结论：SQL Server不会存储完整的连接字符串，尤其是包含密码等敏感信息的部分，这是出于安全设计的考虑。不过你可以通过DMV获取连接的关键属性，间接还原部分连接字符串的核心内容：

• 从sys.dm_exec_connections可以拿到：client_net_address（客户端IP）、local_net_address（服务器IP）、auth_scheme（认证方式）等连接层面的属性。
• 从sys.dm_exec_sessions可以拿到：program_name（应用程序名称，通常会在连接字符串里配置）、login_name（登录名）、default_database_name（默认数据库）等会话层面的属性。

举个通过会话ID查询这些属性的例子：

SELECT
    s.session_id,
    s.program_name,
    s.login_name,
    s.default_database_name,
    c.client_net_address,
    c.auth_scheme
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
WHERE s.session_id = @YourSessionID

为什么拿不到完整连接字符串？原因有两点：

1. 连接字符串里的密码不会被客户端驱动传递给SQL Server，仅用于认证过程，认证完成后就会被丢弃，不会存储在任何系统视图中。
2. 连接池相关的配置参数（比如MAX Pool Size）是客户端侧的设置，SQL Server本身不会追踪这些参数。

二、实现连接池耗尽的主动预警 #

你提到的核心痛点是识别不同的连接池，其实SQL Server的sys.dm_exec_connections里有个connection_pool_id字段——同一个连接池的所有连接会共享这个ID，这正是区分不同连接池的关键标识！

关键思路：

1. 以connection_pool_id为分组依据，统计每个连接池的活跃用户连接数。
2. 结合你预设的MAX Pool Size（比如5），设置预警阈值（比如4）。
3. 定时执行统计查询，当达到阈值时触发预警。

示例预警查询（排除系统会话）：

WITH PoolUsageStats AS (
    SELECT
        c.connection_pool_id,
        COUNT(*) AS current_connections,
        -- 收集更多上下文信息方便后续排查
        STRING_AGG(DISTINCT s.program_name, ', ') AS associated_apps,
        STRING_AGG(DISTINCT s.login_name, ', ') AS linked_logins,
        STRING_AGG(DISTINCT c.client_net_address, ', ') AS client_ips
    FROM sys.dm_exec_connections c
    JOIN sys.dm_exec_sessions s 
        ON c.session_id = s.session_id
        AND s.is_user_process = 1 -- 仅统计用户会话，排除系统会话
    GROUP BY c.connection_pool_id
)
SELECT *
FROM PoolUsageStats
-- 替换为你的预警阈值：比如MAX Pool Size=5时，阈值设为4
WHERE current_connections >= 4

实现主动预警的步骤：

1. 确定每个连接池的MAX Pool Size：由于SQL Server不存储这个客户端配置，你可以通过两种方式解决：
   • 在应用的连接字符串里把MAX Pool Size嵌入到program_name中（比如program_name=MyApp_MaxPool5），这样在查询里可以解析该字段获取对应阈值。
   • 维护一个自定义配置表，记录每个connection_pool_id对应的MAX Pool Size（适合连接池固定的场景）。
2. 设置定时任务：用SQL Agent创建一个作业，每分钟执行上述查询。如果查询返回结果，就通过Database Mail发送预警邮件，内容包含连接池ID、当前连接数、关联应用等关键信息。
3. 额外优化：可以创建日志表记录每个连接池的连接数变化趋势，方便后续排查连接池耗尽的根源。

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