我应该保留这个"GlobalConnection"还是为每个查询创建连接？

Question

我继承了一个使用ADO连接到SQL Server的传统Delphi应用程序.

该应用程序有一个"全局连接"的概念 - 它是一个在开始时打开的单一连接,然后在整个应用程序运行期间保持打开状态(可以是几天,几周或更长时间...... )

所以我的问题是:我应该采用这种方式做事还是应该切换到"connect-query-disconnect"做事方式？有关系吗？

切换将是一项非常重要的任务,但如果它意味着更好的性能,数据管理等,我会这样做.

Answer 1

嗯,这取决于你期望从中得到什么,以及它是什么样的应用程序.

使用单个长时间运行连接没有什么特别的错误,只要应用程序可以正常处理断开连接并在无法重新连接时恢复或记录/通知.

connect-query-disconnect设置的问题在于您添加了在每个查询上连接和断开连接的开销.这会减慢速度,在交互式GUI应用程序中,用户可能会注意到额外的开销.您还必须确保授权透明地处理(如果尚未透明).

同时,如果您可以将所有查询推送到后台线程并异步更新GUI,则可能会获得交互式性能提升.如果由于查询被序列化而出现争用,您可以相当容易地迁移到连接池系统并进一步改进.虽然这具有相当高的复杂性成本,但现在您正在寻求平衡收益与所涉及的工作的比较.

现在,我的最终回应是"如果没有破产,就不要修理它".你提出的改变是很多工作 - 这个应用程序的用户可以获得多少收益？还有其他问题可以解决,可能会使他们受益更多吗？

编辑:好的,所以它破了.好吧,至少缓慢,这对我来说都是一样的.如果你已经排除了SQL Server本身的问题,并且查询的执行速度尽可能快(即数据库模式是理智的,正确的索引可用,查询不是完全脑力,服务器有足够的RAM和足够快I/O,网络不是片状等等,然后是的,现在是时候找到提高应用程序本身性能的方法了.

简单地转移到连接查询 - 断开连接将使事情变得更糟,并且您发出的查询越多,下降就越大.听起来你需要重新构建应用程序,这样你就可以运行更少的查询,在后台运行它们,在客户端上更积极地缓存,或者所有3个的组合.

不要忘记让客户端表现更好意味着服务器端性能变得更加重要,因为如果客户端开始建立多个连接并并行发出多个查询,它可能会处理更高的负载.

Answer 2

正如弗雷泽先生之前所说的那样，一个全球性的联系本身并不坏。

如果您打算更改，首先要检测问题是什么。让我们看看一些场景：

1

某些屏幕（IOW：一组在业务实体中操作的 1..n 表单）速度很慢。可能的原因：

1. 过滤不充分导致大量记录在不必要的情况下从数据库中提取。
2. 记录的数量还可以，但渲染它需要太多时间。解决方案：更快的控件或智能渲染（例如：虚拟列表视图）
3. 每次打开屏幕时查询太多。可能的解决方案：使用 TClientDatasets（或任何内存数据集）来保存不经常修改的查找表。更复杂的缓存用于更广泛的表或在其他线程中打开这些数据集可以缩短响应时间。
4. 在绑定了控件的数据集上滚动可能会很慢（请记住，因为这些小细节很容易被遗忘）。

2

整个应用程序只会变慢。清单：

1. 网卡好吗？即使在良好的结构化网络上，一些网卡故障也会造成严重破坏，因为它们会在线路上产生不必要的噪音。
2. [MSSQL DBA HAT ON] 下一个攻击线是 SQL Server。要求 DBA 跟踪块和死锁。注册慢查询并加快处理速度。这与 #1.1 和 #1.3 直接相关
3. 检测是否有一些天真的开发人员进行了SELECT内部交易。在读提交隔离中，这只是开销，因为它会创建更多的网络流量。打开查询，检索数据并关闭数据集。
4. 如果可以，请查看数据库架构。
5. 是否在应用程序上完成了对大量记录的任何数据绑定操作（比方说，评论部分/多数/所有产品的价格）？做一个 SP 或重构一个查询的操作，它会快得多，并且会减少整个服务器的负载。
6. 对一组记录进行广泛的操作？了解如何在服务器上一次性执行这些操作，而不是逐一记录。请参阅MSSQL MVP Erland Sommarskog 关于数组和 MSSQL 列表的文章中对最常用替代方案的检查。
7. 谨防WHERE类似 :的查询WHERE SomeFunction(table1.blabla) = @SomeParam。大多数情况下，那些不会使用索引导致读取整个表以选择所需的数据。如果是一个大表......在持久计算列上建立索引可以创造奇迹......[MSSQL HAT OFF]

这就是我能想到的，没有更多细节...... ;-)