数据库的连接数对应用系统性能的影响

编写数据库应用程序的时候往往要考虑到系统的并发度和性能。

如系统可以同时支持多少客户端连接？

单笔交易的平均执行时间？

 

对幷发性的需求和处理需要考虑：

1.服务器硬件性能(cpu,内存，IO)

2.网络带宽

3.数据库设计

4.应用程序设计

 

每个方面都对性能产生重要影响，因此在设计有优化系统的时候要全面考虑。

 

今天谈下关于"数据库连接"这个点的思考。（sql server下）

在事务量很频繁的类型的应用程序设计的时候。人们往往会考虑数据库连接的因素。而我发现，可能有的人对这个方面的思考有点误区。这个误区就是:连接数越多，对数据库性能影响越大。

答案是不一定。以 sql server为例说明：

数据库连接数：同时连接到数据库服务的客户端连接的数量。

sql server不同的版本(企业版，标准版)对这个连接有不同限定。连接在空闲状态下本身占用的资源很少，每个连接至少占1KB的内存。

执行线程数：数据库服务器用来执行他的一系列工作(比如编译sql,产生查询计划，读取数据，锁管理，产生检查点，事务管理等等数据库工作内容)的工作线程数量。

sql server 对线程最大数有一个建议，如下：

cpu数量    32位系统     64位系统

<=4    256        512

8      288        576

16     352        704

32     480        960

当一个客户端连接到数据库服务器的时候，默认情况下，将产生一个新的执行线程来处理这个连接。服务器有一个最大执行线程数的参数max work threads来设定最大的执行线程数。当连接数超过这个线程数的时候，连接的请求发生时，若没有空闲线程，将等待，知道有空闲的线程来执行连接的查询请求。max work threads的默认值是0，表示由服务器通过公式(cpu数量-4)*8+256自己决定，基本上如上表。

 

因此可以看出，当执行线程数有限时，服务器利用了线程池和线程排队的能力。真正决定sql server效能的是实际的活动查询请求以及每次查询或更新的频率和处理强度。连接数即使很多，加上企业版sql server对连接数没有限制，我们创建了1000个连接，但是若大部份时间里都是空闲的，也无碍。连接本身对资源的耗费有限。

 

 

“连接数越多，对数据库性能影响越大。”这个论断应该来源于早期非windows系统的服务器。比如早期的oracle版本，在unix系统下，对每个客户端连接产生一个进程，进程管理(切换，调度)对系统资源的耗费是比较大的，因此不会轻易运用诸如“进程pooling”这样的功能。所以那时的oracle下，连接时异常宝贵的。因此oralce就会有像MTA、连接管理器这样辅助连接架构。应用程序本身也流行由c/s的客户端直接面对数据库的结构，改为客户端/应用服务器/数据库服务器的三层架构，以使系统具备更大的扩展性。

 

然而windows下，线程的管理的成本是比较低的。而且数据库的连接处理架构也存在不同，因此，“连接异常宝贵”的结论也不再绝对。

 

我接触过很多系统，一开始就被这个错误论断所影响，而且都采取了“假三层”的架构(对数据库的更新和查询通过一台或几台中间的转发服务进行，而业务逻辑仍然在客户端)。这种方式最后的实施结果是，还不如直接用c/s结构连接来得快，差很多，而且由于中间的自己开发转发socket服务器设计的并不是很好，受网络影响容易掉线。

 

所以，不能一概而论，对不用的应用类型。可以选择不同成本的开发考虑。让价值最大化。在对大型高幷发的系统中，必须要考虑包含连接数在内的多个方面的整体因素。而如果不是高幷发要求的话，基于成本考虑，c/s结构的开发高效率和低成本，也是很划算的。