标签：不能 经验 action 日常 open bsp process select 关注
SQL Server的User Connection确实会占用资源，这一点没有问题。 然而，根据我们的经验，User Connection过多并不会直接导致SQL Server的性能问题。（SQL Server曾出现过一个已知问题，确实是由于多个连接导致，然而这个已经SQL Server 2005 SP3中修复了，参考http://support.microsoft.com/kb/937745/EN ）
因为很多User Connection都处于sleeping的状态,是不占用SQL Server的线程的. 根据我们的情况这种连接并不会造成性能问题.
然而，如果Connection是active connection，比如这个connection正在运行，或者虽然没有执行语句，但是transaction没有COMMIT，这两种都会占用工作线程。占用工作线程才是占用了主要的资源，除了working thread以外，这种连接还会占用锁资源从而会引起对其他连接的阻塞，导致性能问题。这种才是我们所日常关注的。
select spid, kpid, open_tran, status, * from sys.sysprocesses
1）如果kpid为0，说明是不占用线程的，如果是kpid不为0，说明是占用线程的。如果我们发现kpid不为0的有很多个（spid<50的为系统进程,不予考虑），那说明多个连接可能会引起性能问题。
2）open_tran如果不为0,说明有未COMMIT的transaction会占用锁资源，这种连接可能会引起其他的连接的阻塞
3）您还可以检查status，你会发现kpid为0的都是sleeping的。
综上所述，直接设置User Connections并不能直接规避性能问题，也不能直接解决性能问题。相反，User Connection设置了上限，相当于把性能问题转化成了连接问题。后果是虽然用户连接少了，工作负载小从而SQL没有性能问题，但是您会发现有更多的连接失败出现。这并不是您所希望的。
4. 对于User Connection的建议
如果您是出于防止网络攻击，或者网络方面的其他考虑，可以考虑将User Connection设置成一定的值。如果出于性能的考虑，直接设置User Connection是一个治标不治本的办法，并不推荐。从连接角度考虑性能问题的话，您更需要关注的是有没有连接造成了其他连接的阻塞。
标签：不能 经验 action 日常 open bsp process select 关注
原文地址：http://www.cnblogs.com/henryagg/p/6364550.html
