在ADO中進行ADO連接中使用ConnectionString，而是以獨立的方式打開Connection對象；這樣，當我們要關閉Connection對象以及要把它設置成Nothing的時候，引用它就很方便了。      

ADO連接這一術語有著幾種不同的、差異微妙的含義。當人們談到某個東西性能多少好時，他們想要表達的意思可能就是在一定的時間之內它完成了多少工作。例如，一個性能好的發動機運行起來更穩定，產生的動力更強大。對于開發小組，你同樣也可能應用這個判斷標準：一個性能好的開發小組工作時比較安靜，而且能夠生產出大量高質量的代碼。

對我來說，ADO連接性能至少意味著兩件事情——我的代碼運行起來有多好，我的開發小組和我本人工作效率怎么樣ADO連接。無論哪一方面，本文介紹的技巧都將起到一定的幫助作用：幫助你更快地編寫代碼，幫助你編寫更快的代碼——安靜地完成這一切，減少這樣那樣的錯誤。本文介紹的技巧主要面向ADO，特別是如何通過ADO訪問SQL Server。但與此同時，我還將涉及一些適用范圍更廣的COM技巧，它們適用于你所編寫的所有ADO連接代碼。

為了了解從哪些SQL Server數據訪問代碼編寫技術、哪些體系、哪些開發習慣可以得到***的性能，我已經花了不少時間。一些情況下，對于應用的整體性能來說，單一的技術意義很小，除非我們通過循環將性能的改善程度成倍放大。

例如，在一個客戶機/服務ADO連接器應用中，當我們不是通過指定ODBC數據源（DSN）的方式連接數據庫時，大約能夠節省一到二秒的時間。對于應用整體的適用性或性能來說，這部分節省的時間所產生的影響很小。但是，如果我們在一個中間層組件上應用這種技術，這個組件每分鐘（或每小時，每天）都要建立和關閉數據庫連接數百（甚至數千）次，那么，這種技術將顯著地影響系統的性能表現。因此，對于我在這里討論的每一種技術，請務必考慮這個倍數因子——即，在一定的時間周期內，ADO連接你的系統將執行同一段代碼多少次。

當你開始尋求改進性能的方案ADO連接時，請考慮一下你的應用（組件，或者是ASP代碼）大部份的等待和處理時間花在什么地方。如果你發現應用程序把大量的時間花在等待Open或Execute方法執行完成，那么，你應該認真地檢查一下服務器端的查詢策略。包括ADO在內，所有的數據訪問接口等待查詢結果的時間都相同。例如，如果你有一個查詢，SQL Server需要20秒才能完成它。#t#

不論用來執行該查詢的是什么接口，沒有一種接口能夠比其他接口以更快的速度返回結果。雖然有些接口打開連接的速度比較快，有些接口處理結果集的速度比較快，但沒有一種接口能夠影響數據庫引擎編譯和執行查詢的速度。因此，如果你的ADO連接查詢具有太高的“挑戰性”——例如你沒有對索引進行優化，你沒有使用存儲過程，服務器負載過重，或者你要求返回的記錄數量太多——那么，世界上沒有一種ADO技術能夠幫助你提高性能。除非你解決了這些基本的查詢問題，否則沒有一種性能調整技術能夠顯著地改善整體性能。SQL Server的Query Analyzer是一個分析查詢性能的優秀工具。它能夠用圖形的方式顯示查詢的執行過程，并對改進性能的方法提出建議。

如果你能夠確信查詢具有較高的效率，那么，你可以使用本文介紹的技術進一步調整ADO代碼的性能。這里介紹的技巧將從各個方面幫助你簡化和改進ADO編程，包括：建立和維護連接，構造和提交執行速度更快的查詢，提高處理查詢結果的ADO連接效率，等等。