Sql 解决VB6中的ADO超时问题

在VB6中填充ADO记录集时遇到问题。当我使用SSMS运行查询时，查询（运行SQLServer2008）只需要大约1秒的时间。当结果集很小时，它工作得很好，但是当它成为几百条记录时，它需要很长时间。800多条记录需要大约5分钟才能返回（在SSMS中查询仍然只需要1秒），6000多条记录需要20分钟以上。我已经通过增加命令超时来“修复”异常，但我想知道是否有办法让它工作得更快，因为它似乎不是需要这么多时间的实际查询。比如压缩结果，这样就不用花那么长时间。记录集按如下方式打开：

myConnection.CommandTimeout = 2000
myConnection.ConnectionString = "Provider=SQLOLEDB;" & _
        "Initial Catalog=DB_NAME;" & _
        "Data Source=SERVER_NAME" & _
        "Network Library=DBMSSOCN;" & _
        "User ID=USER_NAME;" & _
        "Password=PASSWORD;" & _
        "Use Encryption for Data=True;"
myConnection.Open

myRecordSet.Open STORED_PROC_QUERY_STRING, myConnection, adOpenStatic, adLockReadOnly
Set myRecordSet.ActiveConnection = Nothing

myConnection.Close

数据返回用于填充组合框的3列

更新： 我运行了SQL Profiler，来自客户机的实例进行了更多的读取，并且比SSM中的查询的两个指标花费了100倍的时间。根据profiler，ssm和客户机的查询文本是相同的，因此我认为不应该使用不同的执行计划。网络库或提供商对此有何影响

探查器统计信息：

• 来自客户端应用程序：7041720 读取，59458毫秒持续时间，3900行 计数
• 从SSMS：30802读取，238毫秒 持续时间，3900行计数

---

看起来它使用的是不同的执行计划，但查询完全相同，如果与SSMS中显示的执行计划不同，我不确定如何检查客户端可能使用的执行计划。

800+记录需要大约5分钟的时间。

=查询问题

看看你的执行计划：

在SSMS中，运行：

将SHOWPLAN\u全部设置为开启状态

然后运行查询，它将不会生成预期的结果集，而是关于数据库如何检索数据的执行计划。大多数糟糕的查询通常是表扫描（查看表中的每一行，这很慢），因此在

StmtText

列中查找单词“scan”。试着弄清楚为什么没有在该表上使用索引（名称将以“SCAN”一词出现）。如果您加入多个表并进行多次扫描，请首先将注意力集中在最大的表上

如果没有更多信息，这是你能得到的最好的“通用”帮助

编辑
通过阅读您的问题，我不确定您的意思是，无论行数是多少，SSMS总是快速的，而VB总是随着行数的增加而缓慢的。如果是这种情况，请检查：

可能类似于：参数嗅探或不一致的连接参数（ANSI null、arithabort等）

对于连接设置，请尝试从SSMS和VB6运行这些设置（将它们添加到结果集中），并查看是否存在任何差异：

SELECT SESSIONPROPERTY ('ANSI_NULLS') --Specifies whether the SQL-92 compliant behavior of equals (=) and not equal to (<>) against null values is applied.
                                      --1 = ON 
                                      --0 = OFF

SELECT SESSIONPROPERTY ('ANSI_PADDING') --Controls the way the column stores values shorter than the defined size of the column, and the way the column stores values that have trailing blanks in character and binary data.
                                        --1 = ON 
                                        --0 = OFF

SELECT SESSIONPROPERTY ('ANSI_WARNINGS') --Specifies whether the SQL-92 standard behavior of raising error messages or warnings for certain conditions, including divide-by-zero and arithmetic overflow, is applied.
                                         --1 = ON 
                                         --0 = OFF

SELECT SESSIONPROPERTY ('ARITHABORT') -- Determines whether a query is ended when an overflow or a divide-by-zero error occurs during query execution.
                                      --1 = ON 
                                      --0 = OFF

SELECT SESSIONPROPERTY ('CONCAT_NULL_YIELDS_NULL') --Controls whether concatenation results are treated as null or empty string values.
                                                    --1 = ON 
                                                    --0 = OFF

SELECT SESSIONPROPERTY ('NUMERIC_ROUNDABORT') --Specifies whether error messages and warnings are generated when rounding in an expression causes a loss of precision.
                                              --1 = ON 
                                              --0 = OFF

SELECT SESSIONPROPERTY ('QUOTED_IDENTIFIER') --Specifies whether SQL-92 rules about how to use quotation marks to delimit identifiers and literal strings are to be followed.
                                             --1 = ON 
                                             --0 = OFF

---

您是否尝试过删除“对数据使用加密”？没有，但这不是一个真正可用的选项。这是一个客户端应用程序。您是否尝试分析调用并验证这绝对不是参数嗅探问题？您正在用6000条记录填充组合框？如果您要用6000行填充组合框，则需要根据原始帖子提供更好的用户界面（将其过滤到可管理的数字），查询在SSMS中以秒为单位运行。查询的文本完全相同（使用SQL Profiler确认）。我已经看过执行计划了，看起来不错。所有的索引都在使用中。比较上面的会话属性确实很有价值，因为它们可能会影响性能，至少在发出一个集合ARITHABORT之后尝试ADO查询，因为它是ARITHABORT属性。谢谢你的帮助。我更改了数据库级别的设置。我想它可能在几天前被重置了，这导致了这个问题的突然出现。我最好的猜测是，当我们重新启动服务器时，它被重置了。

SELECT
    col1, col2
        ,SESSIONPROPERTY ('ARITHABORT') AS ARITHABORT
        ,SESSIONPROPERTY ('ANSI_WARNINGS') AS ANSI_WARNINGS
    FROM ...