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

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

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

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

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

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

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

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