|
數(shù)據(jù)檢索優(yōu)化應用程序
|
|
SQL 語言的功能之一是能夠在服務器上篩選數(shù)據(jù)，以便只給客戶端返回最少的所需數(shù)據(jù)。使用這些功能可使服務器與客戶端間的高耗費的網(wǎng)絡流量減到最小。這意味著必須使 WHERE 子句的限制性足夠強，從而使其只檢索應用程序所需的數(shù)據(jù)。
若是在服務器上篩選數(shù)據(jù)，則效率始終會高于將數(shù)據(jù)發(fā)送到客戶端、然后在應用程序中篩選數(shù)據(jù)。這種情況也適用于從服務器請求的列。發(fā)出 SELECT * FROM... 語句的應用程序要求服務器將所有列數(shù)據(jù)返回給客戶端，不論客戶端應用程序是否已綁定這些列以在程序變量中使用。按名稱只選擇必要的列可避免不必要的網(wǎng)絡流量。這也使應用程序在表定義更改時更可靠，因為新添加的列不返回給客戶端應用程序。
性能還取決于應用程序如何從服務器請求結果集。在使用開放式數(shù)據(jù)庫連接 (ODBC) 的應用程序中，在執(zhí)行查詢前設置的語句選項決定應用程序如何從服務器請求結果集。當保留語句選項的默認值時，Microsoft? SQL Server? 2000 以最有效的方式發(fā)送結果集。
SQL Server 假定應用程序立即從默認結果集中提取所有的行。因此，該應用程序必須緩沖那些不立即使用但以后可能需要的行。這種緩沖需求決定了（通過使用 Transact-SQL）僅指定所需的數(shù)據(jù)尤其重要。
請求默認結果集并只按應用程序邏輯或應用程序用戶的需要提取行這一做法看起來很節(jié)省，但卻是假節(jié)省。未從默認結果集中提取的行會阻礙與服務器的連接，并阻塞同一事務中的其它工作。另外，未從默認結果集中提取的行會導致 SQL Server 在服務器上控制鎖，從而有可能防礙其他用戶更新。在小規(guī)模測試中可能不會出現(xiàn)這種并發(fā)問題，但是以后部署應用程序時則會出現(xiàn)該問題。因此，應立即從默認結果集中提取所有的行。
有些應用程序無法緩沖它們從服務器請求的所有數(shù)據(jù)。例如，如果應用程序查詢大表并允許用戶指定選擇條件，則可能不返回任何行或返回上百萬行。而用戶不大可能想查看上百萬行。相反，用戶更有可能縮小選擇條件重新執(zhí)行查詢。在此情況下，提取和緩沖上百萬行，而用戶最終丟棄這些行，無疑是浪費時間和資源。
對于這些應用程序，SQL Server 提供服務器游標以允許應用程序從任意大的結果集中提取小的行子集或行塊。如果用戶想看到同一結果集內(nèi)的其它記錄，服務器游標允許應用程序從結果集中提取任何其它行塊，包括結果集內(nèi)后面的 n 行、前面的 n 行或從某行開始的 n 行。SQL Server 只根據(jù)需要執(zhí)行每個塊提取請求，而且 SQL Server 通常不在服務器游標上的塊提取之間控制鎖。
服務器游標還允許應用程序對提取的行執(zhí)行定位更新或刪除，而無須確定行的源表和主鍵。如果行數(shù)據(jù)從提取到請求更新的這段期間內(nèi)更改，SQL Server 會檢測出這個問題并防止丟失更新。
但是，服務器游標的功能需要一定的代價。如果給定查詢的所有結果都要在應用程序中使用，則服務器游標總是比默認結果集消費高。默認結果集始終只需要在客戶端和服務器間往返一次，而每次用服務器游標調(diào)用提取行塊操作便導致一次往返。此外，服務器游標消耗服務器上的資源，對某些類型的游標可以使用的 SELECT 語句也有限制。例如，KEYSET 游標被限制為只能使用帶唯一索引的表，而 KEYSET 和 STATIC 游標大量使用服務器上的臨時存儲。由于這些原因，只有應用程序需要服務器游標功能時才使用這些服務器游標。如果某個任務通過主鍵請求單個行，則使用默認結果集。如果另外一個任務需要大得無法預料的結果集或可更新的結果集，則使用服務器游標提取大小適中的塊（例如一次提取一屏行）。另外，只要可能就應對自動提取使用快速只進游標。可以使用這些游標只在客戶端和服務器之間往返一次而檢索出小結果集，這與使用默認結果集相似。
|
|
| |
|
|
|
|
|
