客戶端提升SQL Server數(shù)據(jù)庫性能

申請免費試用、咨詢電話：400-8352-114

第一：編寫限制搜索范圍的查詢語句。

眾所周知，在數(shù)據(jù)庫查詢的時候返回記錄的多少直接關(guān)系到查詢的效率。所以，在客戶端通過一定的條件語句，限制搜索的范圍，往往可以大幅度的提高查詢的效率。

如用戶在客戶端查詢數(shù)據(jù)庫的時候，在查詢語句中，加入TOP語句，讓其顯示前面的50條或者100條記錄。因為根據(jù)經(jīng)驗，用戶在查詢數(shù)據(jù)的時候，60%左右要查看的都是靠前面的記錄。特別是在一些歷史交易信息表中，如在erp系統(tǒng)的庫存交易表中，就可以只顯示前面幾百條的記錄，而不需要顯示所有的記錄。當用戶覺得記錄不夠時，可以按“全部”，然后客戶端再去服務(wù)器查詢所有的結(jié)果。這種設(shè)計的話，就可以非常有效的提高數(shù)據(jù)庫的查詢性能。

如可以在在客戶端設(shè)置默認的條件語句。如在ERP系統(tǒng)中，有個采購定單的表單;在后臺數(shù)據(jù)庫中，就對應(yīng)著采購定單這么一張表。默認在查詢采購定單的時候，查詢到的是未結(jié)帳的采購定單。如此的話，即使用戶在查詢采購單時，沒有輸入采購定單號或者定單日期等限制條件，客戶端在向服務(wù)器遞交查詢語句的時候，會默認把限制條件語句加入進去。如此，對于提高數(shù)據(jù)庫首次查詢的效率是非常有幫助的。

當然，無論是利用TOP語句，還是利用Where語句設(shè)置默認的限制條件，都不是隨便設(shè)置的。這往往需要根據(jù)客戶的使用習慣與表單的性質(zhì)，來進行確定。如對于客戶信息表，其客戶本來數(shù)量也不多，所以，就沒有必要設(shè)置限制搜索范圍的查詢語句。但是對于庫存交易明細表，一個月下來，就有可能有成千上完條記錄。如此海量的數(shù)據(jù)，若不設(shè)置限制條件的話，則查詢起來，用戶等待的時間會比較長。所以，針對這種情況，我們默認可以其只顯示前面500條記錄或者只顯示最近30天之內(nèi)的交易信息。

總之，在客戶端適當?shù)募尤胂拗扑阉鞣秶牟樵冋Z句，是在客戶端提高數(shù)據(jù)庫服務(wù)器性能的一個首選的方法。

第二：盡量不要采用復(fù)雜的存儲過程。

SQL Server數(shù)據(jù)庫雖然提供了很強的存儲過程功能，但是，在前臺應(yīng)用程序設(shè)計的時候，最好不要頻繁的去調(diào)用數(shù)據(jù)庫的存儲過程。這主要是因為存儲過程雖然方便，但是其執(zhí)行速度沒有普通的應(yīng)用程序，如C語言那么快。

而從功能上看，很多存儲過程可以完成的功能，前臺應(yīng)用程序完全可以實現(xiàn)。如在一些進銷存管理系統(tǒng)中，往往需要把小寫金額轉(zhuǎn)換成大寫金額，在采購定單上打印出來。這個功能即可以通過數(shù)據(jù)庫的存儲過程實現(xiàn)，也可以通過前臺的應(yīng)用程序?qū)崿F(xiàn)。但是，根據(jù)筆者的觀察，發(fā)現(xiàn)數(shù)據(jù)庫的存儲功能的性能不是很理想。若存儲過程稍微比較復(fù)雜的話，如參數(shù)比較多時，客戶端的響應(yīng)時間就會比較慢。相反，如果不是在數(shù)據(jù)庫后臺實現(xiàn)這個功能，而是直接在前臺利用應(yīng)用程序?qū)崿F(xiàn)的話，則其速度就會快許多。

另外，若在后臺數(shù)據(jù)庫中建立存儲過程的話，會增加服務(wù)器的工作量。設(shè)想一下，現(xiàn)在采購部門有十個員工，若在一個時段內(nèi)，都在維護采購定單的話，則就要同時調(diào)用這個存儲過程，那么對于服務(wù)器的資源就會“爭用”。相反，若在客戶端實現(xiàn)這個功能的話，因為其都是在客戶端上執(zhí)行，所以服務(wù)器資源大家就不用你爭我奪了。

所以，筆者在數(shù)據(jù)庫設(shè)計的時候，很少采用存儲過程。能夠利用客戶端應(yīng)用程序?qū)崿F(xiàn)的，就采用前臺應(yīng)用程序?qū)崿F(xiàn)。真的要采用存儲過程的話，也要采用那些減少爭用和增加并發(fā)性的存儲過程。

第三：在客戶端采用高速緩存提高服務(wù)器性能。

我們都知道，數(shù)據(jù)庫在設(shè)計的時候，也用到了緩存。緩存是操作系統(tǒng)內(nèi)存中間的一個模塊。因為從內(nèi)存中讀取數(shù)據(jù)要比在硬盤中讀取數(shù)據(jù)要快的多，所以，在數(shù)據(jù)庫中通過把擁護查詢過的數(shù)據(jù)記入到緩存中去，從而可以服務(wù)器的性能。

現(xiàn)在有些程序開發(fā)人員更進一步。在客戶端應(yīng)用程序上，也可以假如緩存?？蛻舳说木彺娓?wù)器端的緩存有異曲同工之妙。當某個用戶查詢了采購定單價格變更記錄的時候，即使用戶關(guān)掉了表，則其查詢的數(shù)據(jù)仍然會在一定時間內(nèi)保存在客戶端的緩存中。當用戶下次需要這方面數(shù)據(jù)的時候，則客戶端就不會直接從數(shù)據(jù)庫服務(wù)器從查詢，而是先從客戶端的緩存中找起。只有客戶端應(yīng)用軟件的緩存中沒有這方面信息的時候，才會把語句反饋給服務(wù)器，從服務(wù)器中提取數(shù)據(jù)。通過這種方式，就可以在客戶端上分擔服務(wù)器的壓力，改善SQL Server數(shù)據(jù)庫的性能。

不過，若在客戶端設(shè)置了高速緩存的話，則最好在應(yīng)用軟件上，增加清除高速緩存的按紐。因為在默寫情況下，我們可能想要知道即使更改的結(jié)果，而不是最后一個看到。如我們在服務(wù)器上，改變了某個金額。但是，由于在客戶端上剛查詢過這方面的數(shù)據(jù)，數(shù)據(jù)內(nèi)容還在緩存中。則仍然顯示的是哪個未改過之前的情況。此時，就需要通過“清除高速緩存”的方法來及時的看到改變后的內(nèi)容。

第四：在前臺實現(xiàn)表的完整性約束。

如果在后臺數(shù)據(jù)庫實現(xiàn)表的完整性約束，如某個字段不能為空的話，則需要經(jīng)過很多個步驟。如客戶端程序先把結(jié)果傳遞給表;然后在存儲的時候，發(fā)現(xiàn)某個字段為空，不符合表的完整性約束的要求;數(shù)據(jù)庫拒絕保存這條記錄，并返回錯誤信息;數(shù)據(jù)庫服務(wù)器把這個結(jié)果傳遞給客戶端。很顯然，這種處理機制比較麻煩。那么有沒有什么簡單的解決方法呢?

其實，我們?nèi)敉ㄟ^前臺的客戶端應(yīng)用程序來實現(xiàn)表的完整性約束，可能對數(shù)據(jù)庫的性能更加的有利。如在前臺的客戶端界面中，有某個字段不能為空。此時，我們就可以在前臺應(yīng)用程序開發(fā)的時候，加一限制，當這個字段為空的時候，不能保存。在前臺客戶端都不能夠保存的數(shù)據(jù)，則當然不會傳遞給后臺的數(shù)據(jù)庫服務(wù)器。通過這種在前臺實現(xiàn)表的完整性約束，就可以減少這個處理的過程?？梢员Ｕ蟼鬟f給后臺數(shù)據(jù)庫的內(nèi)容都是符合完整性約束的。

另外，就拿默認值來說，也是在客戶端應(yīng)用程序中實現(xiàn)來的便捷。如筆者在數(shù)據(jù)庫開發(fā)的時候，需要有一個記錄創(chuàng)建與更新日期。這兩個字段的話，就可以在為其創(chuàng)建默認日期?，F(xiàn)在的問題就是是在前臺客戶端程序?qū)崿F(xiàn)呢，還是在后臺的數(shù)據(jù)庫中實現(xiàn)限制呢?筆者比較傾向與前臺。因為在前臺，客戶端直接會把當前的默認值傳遞給服務(wù)器，服務(wù)器直接保存即可。而不用觸發(fā)服務(wù)器的默認日期的存儲過程。

總之，筆者認為，我們在考慮改善數(shù)據(jù)庫性能的時候，需要客戶端與服務(wù)器端一起努力?；蛟S通過這種方式，可以給我們一些意外的收獲。使用過后，大家可能都會由衷的發(fā)表感嘆，認同筆者的做法。（IT專家網(wǎng)）