请问这个数据库的 连接/关闭 操作是否会影响效率？- 怎样提高效率？

[CTO]

用户每次打开一个asp.net页面，页面会建立一个数据库连接，然后根据这个页面上的用户ID来查询数据库的内容，待查询完毕则关闭这个链接 （DB conneciton)。最高时期同时在线的用户量达到10万个。

请问这个数据库的 连接/关闭 操作是否会影响效率？- 怎样提高效率？

[以专业开发人员为伍]

如果你的“逻辑连接”底层是连接池，那么你就应该尽可能早地关闭逻辑连接，好让物理连接回到连接池里重复使用。 当然如果你有连续的5个操作要执行，你当然应该使用同一个逻辑连接。但是如果连接之后，需要“发呆”3秒钟等用户交互点一下按钮才继续操作，那么你就应该先把逻辑连接关闭，等用户点了按钮之后才申请另外一个逻辑连接。 由于有连接池机制，所以逻辑连接只是获取数据库连接的key，它根本不等于数据库的物理连接，不能用后者的概念来套用到前者。

[CTO]

非常感谢，asp.net 的主数据是DB1 （保存主要信息）, 而这个特定页面的信息是从DB2里面读取的 。 之所以这样设计是因为这个页面的数据都是些临时缓存信息，一天内有效。 DB1是通过web service 连接的，DB2是通过ado.net 连接的，都是Windows认证方式。 DB1 和 DB2 保存在不同硬盘，以增加每个数据库的I/O。 请问这样的设计会否增加系统的性能负载 - 开发人员担心要另打开一个数据库连接会影响系统性能？

[wyumening]

ado.net默认情况是开启连接池机制的，所以连接并不是每一次都会重新生成一个，可以重用的，为了提高效率，要注意在最后一步打开连接，执行完了之后尽早关闭，这样才能提高效率

[csharpcn]

如果硬件配置不好，数据过多，应该会影响效率。 如果通过技术解决比较难，可以用变通的方法，把数据库中相应的大的分成几个小的数据表，然后做一个索引表，这样查询的时候，就应该会快一些，但是要把数据表之间的逻辑关系做好。

[CTO]

不讨论配置的问题，因为DB1和DB2 硬件一样； DB1里面有200个表， 大概100GB左右； DB2有2个表， 1GB左右。 现在的担心是打开/关闭一个数据库(DB2) 连接会影响系统性能？还是直接链接到DB1效率会更高。

[winner2050]

铁打的原则 最晚实例化，最早释放。

[以专业开发人员为伍]

引用 2 楼 CTO 的回复:

非常感谢，asp.net 的主数据是DB1 （保存主要信息）, 而这个特定页面的信息是从DB2里面读取的 。 之所以这样设计是因为这个页面的数据都是些临时缓存信息，一天内有效。 DB1是通过web service 连接的，DB2是通过ado.net 连接的，都是Windows认证方式。 DB1 和 DB2 保存在不同硬盘，以增加每个数据库的I/O。 请问这样的设计会否增加系统的性能负载 - 开发人员担心要另打开一个数据库连接会影响系统性能？

这看不出什么倾向，这实在是太普通了。我想你们的“开发人员”有点过于敏感了。 一个程序打开两个数据库的连接，这是很正常的事情。一个、两个、更多个数据库的编程，都是一样的原则，就是应用程序把逻辑连接不用时立即关闭（而不是考虑等待个1、2秒钟给其它执行代码“共享”）。连接池会自动管理实际的物理连接合适释放的问题，当连接“很忙”的时候可能你释放逻辑连接1000次也不会造成1次物理连接释放，当连接“很闲”的时候可能你释放两次逻辑连接之后过一段时间物理连接就释放了，总之是由连接池来管理的，你的“开发人员”根本不编程来控制底层物理连接合适关闭（他只需要编程控制应用层的逻辑连接尽早关闭），他不必对连接问题太敏感。 对于开发人员，本着一个“用可执行的东西来说话”的原则，如果他觉得“会影响系统性能”那么就请写出至少一个（一、二十行的）测试程序来，给出数量化的对比。否则（如果考虑不清楚如何写测试的话）就应该把精力放在创造性方面，而不是理论是非方面。

[以专业开发人员为伍]

从你的描述看不太明白 DB1、DB2 跟应用服务程序之间的确切关系。只能猜一些。 应用程序如果要访问本机上写好的业务服务，不要通过webservice绕路。尽管你的网站可能对外提供webservice服务，也不太应该“为了省点事儿”而用webservice客户端方式来访问“自己”。凡是能直接访问本进程的过程的，当然要直接调用相应过程。 缓存应该是在asp.net进程的Cache。如果换存在另外一个数据库中，其实没有多大意义。因为缓存本来就应该是随时可以清除的才叫做缓存。所以我想你们的 DB2 并不什么缓存，只是过一段时间要清除的数据而已，那么DB2的数据放到DB1中也没有什么不可以的，这主要还是看方便性吧，这样设计其实跟性能没有太大关系。真要缓存，就用RAM，而且要保证即使自动清除了RAM中的数据，也能在下次查询缓存数据时自动把数据重新读入RAM。

[devmiao]

不会的，连接内部有连接池其实不是每次都创建连接的

[以专业开发人员为伍]

引用 5 楼 CTO 的回复:

不讨论配置的问题，因为DB1和DB2 硬件一样； DB1里面有200个表， 大概100GB左右； DB2有2个表， 1GB左右。 现在的担心是打开/关闭一个数据库(DB2) 连接会影响系统性能？还是直接链接到DB1效率会更高。

我没有测试过是否应该“仅打开一个数据库”的问题，似乎没有人提过过这方面的疑问。如果你们担心，那就测试一下。 通常我们根据“更大更远的目的”来决定是使用一个数据库还是两个，而不是为这类眼前的目的就要将数据分库。不过假设你的DB1的读写操作非常频繁、已经成为了瓶颈，那么拆分出DB2应该是一个倾向于“好的方向”的临时解决办法，我觉得不需要过分怀疑、挑剔它有什么小问题，它一定是抱着“用小牺牲来解决大问题”的目的来尝试分库的。但是是否真的提高了性能（或者可能降低一点性能），还是需要用测试来说话。

[CTO]

非常感谢，你回答了我第一个问题，我想你的意思是可以的，因为连接池在ado.net里建立，和DB1主连接没关系； DB2同样可以建立连接池。 第二个问题我没有说人为编程作甚么，只是用户达到10万，是否每个人连接的时候都需要建立一个连接呢？还是可以重复使用其他人的连接 （在ado.net的连接池内）？ 如果每个人都需要自己的连接，那么会不会出现连接池“过满”的现象，影响系速度呢？

[CTO]

可否解释一下 逻辑连接 和 物理连接？

这个程序的主DB是DB1， 启动就连接到DB1了；那么这个界面要访问DB2，是否可以建立逻辑连接呢？ （是不是connection pooling）?

[CTO]

其实我的问题准确的描述是： 1. 这个程序的主DB是DB1， 启动就连接到DB1了；那么这个界面要访问DB2，是否也可以建立连接池呢 （尽管主程序已经使用了DB1 - 连接池有DB1的连接）？ 2. 这个程序的用户多达10万，Windows认证方式，是否他们可以重复使用连接池里面的链接呢？还是根据用户名要存储10万个连接在链接池里面？

[wyumening]

引用 13 楼 CTO 的回复:

其实我的问题准确的描述是： 1. 这个程序的主DB是DB1， 启动就连接到DB1了；那么这个界面要访问DB2，是否也可以建立连接池呢 （尽管主程序已经使用了DB1 - 连接池有DB1的连接）？ 2. 这个程序的用户多达10万，Windows认证方式，是否他们可以重复使用连接池里面的链接呢？还是根据用户名要存储10万个连接在链接池里面？

ado.net 自身有连接池的，连接池的创建，什么时候重用连接，什么时候建立新的连接，本身会自动管理的，还是不要人为编程控制的好，如果考虑性能问题，可以做个测试看看

[以专业开发人员为伍]

如果你的DB1、DB2与应用都在同一个主机上，都是本地访问数据库，那么其实“两个数据库分到不同驱动器”的价值真的很难看到。还不如把硬盘换一个快一些的、贵一些的，这可以明显看到效果。 而应用程序提高进程内数据 Cache 的使用，在“数据库前边”挡住大量的查询请求，也能明显看到效果。