哼，问题在于ADO reocrdsets是非托管代码。结果，.net将不得不在托管和非托管代码之间不断地“封送”。其中包括将数据类型与.net变量类型进行封送处理。那要花钱。

我的意思是，您可以尝试以下代码作为测试：

    Dim t As DateTime
    Debug.Print("start")

    t = Date.Now

    Using con As New SqlConnection(My.Settings.Test3)
        Dim strSQL As String = "SELECT * from tblHotels where ID  = @ID"
        Dim cmdSQL As New SqlCommand(strSQL,con)
        cmdSQL.Parameters.Add("@ID",SqlDbType.Int).Value = 19
        con.Open()
        Dim rst As New DataTable
        For i = 1 To 10000
            rst.Clear()
            rst.Load(cmdSQL.ExecuteReader)
        Next

    End Using

    Debug.Print("time = " & ((Date.Now.Ticks - t.Ticks) / 10000000).ToString)

现在，我正在运行具有1.7 GHz i3（非常低端）的自卸式消防笔记本电脑。

我得到的时间超过了6.6428576秒，或者说是6642百万秒。

我猜想如果硬件更好，以上内容将再次下降一半。

现在，假设您已注意到这是一个非常大的应用程序？与非托管代码（例如ADO）相对，转换和使用.net sql提供程序对象将是一个优势。

当然，问题在于您有一个大型应用程序，但我并非所有人都认为从遗留ADO转换（移开）是否可行。

因此，其中很大一部分可能是由于ADO的非托管代码将与本机打交道（非常酷的.net CLR优化器在大多数情况下可以做得很好）性能。但是，.net代码优化器只能在.net“托管”代码上运行，而不是非托管代码库。

现在，我可以将上面的代码尝试作为ODBC以及oleDB提供程序的代码（我敢打赌，它们的性能都将与我上面使用的sqlProvider相似）。

您也可以尝试将项目强制为x64，但是我不确定x64位ADO提供程序是否可用。

那么，现在和到目前为止？我认为这个问题很大程度上是由于在这里使用非托管ADO代码所致。我会说尝试与我发布的内容类似的测试存根。 （您的硬件要比上面测试过的我的垃圾箱budjet笔记本电脑更好）。

POSSILE迁移可以使用oleDB提供程序，因为这应该使语法保持相似，但是如上所述，我再次使用本机DataTable对象。 （如果您使用这些原生.net对象，例如datarow，datatable等，则它们100％相同

sql provider in .net (best choice)
oleDB provider in .net (a good choice when migration from VB6)

ODBC provider in .net (I like this if you ever want to swap database in future
and in fact ODBC is a better choice then say oleDB providers. And ODBC is making a
strong comeback in the marketplace with robust re-connection options for say SQL Azure

最后的选择是什么？好吧，那将使用对ADO旧式库的外部引用。

当某人从VB6转换到vb.net时，这里的问题真正开始了。那是应该发生的，并且远离ADO传统（不受管理）的迁移。

无论如何，请尝试上面的代码。我建议上面提到的所有3个.net提供程序都应执行类似的操作。并且请记住，以上操作是在运行1.7GHz的底部进纸器笔记本电脑上运行的。