SQL Server應(yīng)用程序性能調(diào)優(yōu)之設(shè)計優(yōu)化
優(yōu)化你的應(yīng)用程序設(shè)計
如果你為應(yīng)用程序使用了多層設(shè)計，SQL Server只是一個大型應(yīng)用程序的一部分。多層設(shè)計的實現(xiàn)方式對應(yīng)用程序性能影響之大，或許會遠遠超乎你的想象，它比SQL Server所帶來的影響大的多。
不幸的是，在應(yīng)用程序性能低下時，人們往往將其原因歸咎于SQL Server，而沒有反思應(yīng)用程序的設(shè)計，實際上很多情況下設(shè)計缺陷才是導(dǎo)致應(yīng)用程序性能問題的主要原因。下面我提供一些可以幫助你進行應(yīng)用設(shè)計的建議，以防止SQL Server繼續(xù)獨擔性能低下的罪名。
在設(shè)計多層應(yīng)用時你首先需要決定的是，選擇邏輯和物理設(shè)計。在這兩種設(shè)計中，物理設(shè)計中最易發(fā)生導(dǎo)致性能問題的錯誤，原因是在這個設(shè)計中要完成理論在真實世界中的實現(xiàn)。和任何其它事情一樣，你面臨著多種選擇，其中很多選擇會帶來升級或性能問題。
為了確定哪一種選擇才是正確的，需要你再次借助于測試手段，在設(shè)計階段就開始早期潛在測試，你可以使用快速原型測試法，來判斷哪一種實現(xiàn)可以最好的滿足用戶的需要。
另外，當你在設(shè)計物理實現(xiàn)時，盡量遵循以下建議，來確保應(yīng)用程序的可升級性和最優(yōu)化性能：
盡可能將以數(shù)據(jù)為中心的任務(wù)以存儲過程的形式在SQL Server上完成。避免在展現(xiàn)層和業(yè)務(wù)層處理數(shù)據(jù)。
不要在業(yè)務(wù)層保存修改狀態(tài)數(shù)據(jù)，盡可能的在數(shù)據(jù)庫中實現(xiàn)。
不要創(chuàng)建復(fù)雜或難懂的對象分級。復(fù)雜類的創(chuàng)建和使用通常會比較耗資源，會降低應(yīng)用程序的性能和擴展性。原因是當創(chuàng)建和釋放這些對象時，內(nèi)存分配操作的開銷通常比較大。在進行應(yīng)用程序設(shè)計時，可以考慮使用微軟事務(wù)處理服務(wù)器（MTS）來充分利用數(shù)據(jù)庫連接池和對象池的優(yōu)勢。MTS可以運行將數(shù)據(jù)庫連接和對象都放到pool中，可以大大提高應(yīng)用程序的整體性能和可擴展性。
如果你的應(yīng)用程序針對SQL Server的查詢耗時較長，在設(shè)計應(yīng)用程序時可以考慮異步進行查詢。這樣一個查詢不用必須等待前面一條執(zhí)行完后才能進行。將這個功能加入到你的多層應(yīng)用軟件的一個辦法是使用微軟消息隊列服務(wù)器（MSMQ）。
雖然按照以上建議并不能確保你獲得一個可升級、快速執(zhí)行的應(yīng)用程序，卻可以說是一個好的開始。
優(yōu)化數(shù)據(jù)庫的設(shè)計
與應(yīng)用程序設(shè)計類似，數(shù)據(jù)庫設(shè)計對SQL Server應(yīng)用程序的可升級性和性能也非常關(guān)鍵。同樣與應(yīng)用程序設(shè)計類似，如果你在開始的時候沒有合理的進行數(shù)據(jù)庫設(shè)計，當應(yīng)用程序被投入到生產(chǎn)環(huán)境中后，再對其進行修改往往非常困難，且代價較高。在設(shè)計SQL Server數(shù)據(jù)庫時，以下幾件事情對其升級和性能非常關(guān)鍵，需要牢記。
同樣的道理，你需要盡可能早的使用真實數(shù)據(jù)來測試你的設(shè)計。這意味著你需要開發(fā)具有示例數(shù)據(jù)的原型數(shù)據(jù)庫，然后使用預(yù)計會在真實應(yīng)用中發(fā)生的行為類型來對該設(shè)計進行測試。
一開始就需要你確定的設(shè)計原則之一是，數(shù)據(jù)庫將被使用來進行聯(lián)機事務(wù)處理（OLTP），還是在線分析處理（OLAP）。在設(shè)計數(shù)據(jù)庫時人們常犯的一個最大錯誤是，試圖設(shè)計數(shù)據(jù)庫同時滿足OLTP和OLAP需要。如果你希望獲得高性能和可擴展性，這兩種應(yīng)用程序類型是互相排斥的。
OLTP數(shù)據(jù)庫通常是高度規(guī)格化的，有助于降低必須存儲的數(shù)據(jù)量。存儲的數(shù)據(jù)越少，SQL Server執(zhí)行的I/O操作就越少，數(shù)據(jù)庫訪問就會越快。事務(wù)處理也盡可能在短時間內(nèi)完成，以減少鎖定沖突現(xiàn)象。最后一點，為降低大量插入、更新和刪除操作的開銷，要盡可能少的使用索引。
另一方面，OLAP數(shù)據(jù)庫則是高度反規(guī)格化的。另外，它不使用事務(wù)處理，因為數(shù)據(jù)庫是只讀的記錄鎖定不是什么問題。當然，為了滿足廣泛的報表需求，需要大量使用索引。
由此可見，OLTP和OLAP數(shù)據(jù)庫實現(xiàn)的目的完全不同，你不可能設(shè)計一個數(shù)據(jù)庫同時滿足這兩種需求。
在數(shù)據(jù)庫設(shè)計早期階段發(fā)現(xiàn)問題后，修改起來相對比較容易，因此不要等到應(yīng)用程序開發(fā)完成后，再去修改數(shù)據(jù)庫設(shè)計，這幾乎是不可能的。
【編輯推薦】
