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

Question

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

应用程序有一个“全局连接”的概念 - 它是一个在开始时打开的单个连接，然后在整个应用程序运行期间保持打开状态（可以是几天，几周或更长时间）。 ...）

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

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

Answer 1

嗯，这取决于你期望从中获得什么，以及它是什么类型的应用程序。

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

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

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

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

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

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

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

Answer 2

正如Frazier先生之前所说的那样 - 一个全球连接本身并不坏本身。

如果您打算更改，请首先检测 WHAT 是否存在问题。让我们看一些场景：

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。在read committed isolation中，它只是开销，因为它会创建更多的网络流量。打开查询，检索数据并关闭数据集。
4. 如果可以，请查看数据库架构。
5. 大量记录上的任何数据绑定操作（比方说，评论部分/大部分/所有产品的价格）是否已在应用上完成？制作SP或重构查询操作，它会更快，并将减少整个服务器的负载。
6. 对一组记录进行广泛的操作？了解如何在服务器上一次执行该操作，而不是逐个记录。请参阅MSSQL MVP Erland Sommarskog's article on array and list on MSSQL对大多数使用过的替代品的检查。
7. 请注意与WHERE类似的问题：WHERE SomeFunction(table1.blabla) = @SomeParam。大多数时候，那些不会使用索引导致读取整个表以选择所需的数据。如果是一个大表......对持久化的计算列进行索引可以创造奇迹... [MSSQL HAT OFF]

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

Answer 3

数据库连接是耗时的资源创建，应尽可能少地创建经验法则，并尽可能多地重用。这就是为什么其他一些技术拥有数据库连接池的原因，这些数据库连接池通常在应用程序/服务启动时建立，然后尽可能长时间地保存并在线程之间共享。

根据您的评论，该应用程序存在性能问题，但如果没有更多细节可以提出任何建议，那将很困难。

应该试着确定什么是慢的 - 所有的查询都是慢的还是只是某些特定的？ 如果只是某些具体的相关性。

我的2美分。