如何提高SQL Server數據庫的性能，該從哪里入手呢?筆者認為，該遵循從外到內的順序，來改善數據庫的運行性能。如下圖：

　　第一層：網絡環境。

　　到企業碰到數據庫反映速度比較慢時，首先想到的是是否是網絡環境所造成的。而不是一開始就想著如何去提高數據庫的性能。這是很多數據庫管理員的一個誤區。因為當網絡環境比較惡劣時，你就算再怎么去改善數據庫性能，也是枉然。

　　如以前有個客戶，向筆者反映數據庫響應時間比較長，讓筆者給他們一個提高數據庫性能的解決方案。那時，筆者感到很奇怪。因為據筆者所知，這家客戶數據庫的記錄量并不是很大。而且，他們配置的數據庫服務器硬件很不錯。筆者為此還特意跑到他們企業去查看問題的原因。一看原來是網絡環境所造成的。這家企業的客戶機有200多臺，而且都是利用集線器進行連接。這就導致企業內部網絡廣播泛濫，網絡擁塞。而且由于沒有部署企業級的殺毒軟件，網絡內部客戶機存在病毒，掠奪了一定的帶寬。不僅數據庫系統響應速度比較慢，而且其他應用軟件，如郵箱系統，速度也不理想。

　　在這種情況下，即使再花十倍、百倍力氣去提升SQL Server數據庫的性能，也是竹籃子打水一場空。因為現在數據庫服務器的性能瓶頸根本不在于數據庫本身，而在于企業的網絡環境。若網絡環境沒有得到有效改善，則SQL Server數據庫性能是提高不上去的。

　　為此，筆者建議這家企業，想跟他們的網絡管理員談談，看看如何改善企業的網絡環境，減少廣播包和網絡沖突;并且有效清除局域網內的病毒、木馬等等。三個月后，我再去回訪這家客戶的時候，他們反映數據庫性能有了很大的提高。而且其他應用軟件，性能也有所改善。

　　所以，當企業遇到數據庫性能突然降低的時候，第一個反應就是查看網絡環境，看看其實否有惡化。只有如此，才可以少走冤枉路。

　　第二層：服務器配置。

　　這里指的服務器配置，主要是講數據庫服務器的硬件配置以及周邊配套。雖然說，提高數據庫的硬件配置，需要企業付出一定的代價。但是，這往往是一個比較簡便的方法。比起優化SQL語句來說，其要簡單的多。

　　如企業可以通過增加硬盤的數量來改善數據庫的性能。在實際工作中，硬盤輸入輸出瓶頸經常被數據庫管理員所忽視。其實，到并發訪問比較多的時候，硬盤輸入輸出往往是數據庫性能的一個主要瓶頸之一。此時，若數據庫管理員可以增加幾個硬盤，通過磁盤陣列來分散磁盤的壓力，無疑是提高數據庫性能的一個捷徑。

　　如增加服務器的內存或者CPU。當數據庫管理員發現數據庫性能的不理想是由內存或者CPU所造成的，此時，任何的改善數據庫服務器本身的措施都將一物用處。所以，有些數據庫管理專家，把改善服務器配置當作數據庫性能調整的一個先決條件。

　　如解決部署在同一個數據庫服務器上的資源爭用問題。雖然我們多次強調，要為數據庫專門部署一個服務器。但是，不少企業為了降低信息化的成本，往往把數據庫服務器跟應用服務器放在同一個服務器中。這就會導致不同服務器之間的資源爭用問題。如把文件服務器跟數據服務器部署在同一個服務器中，當對文件服務器進行備份時，數據庫性能就會有明顯的下降。所以，在數據庫性能發現周期性的變化時，就要考慮是否因為服務器上不同應用對資源的爭奪所造成的。

　　故，筆者建議，改善數據庫性能時第二個需要考慮的層面，就是要看看能否通過改善服務器的配置來實現。

　　第三層：數據庫服務器。

　　當通過改善網絡環境或者提高服務器配置，都無法達到改善數據庫性能的目的時，接下去就需要考察數據庫服務器本身了。首先，就需要考慮數據庫服務器的配置。

　　一方面，要考慮數據庫服務器的連接模式。SQL Server數據庫提供了很多的數據庫模式，不同的數據庫連接模式對應不同的應用。若數據庫管理員能夠熟悉企業自身的應用，并且選擇合適的連接模式，這往往能夠達到改善數據庫性能的目的。

　　其次，合理配置數據庫服務器的相關作業。如出于安全的需要，數據庫管理員往往需要對數據庫進行備份。那么，備份的作業放在什么時候合適呢?當然，放在夜晚，夜深人靜的時候，對數據庫進行備份最好。另外，對于大型數據庫，每天都進行完全備份將會是一件相當累人的事情。雖然累得不是我們，可是數據庫服務器也會吃不消。差異備份跟完全備份結合將是改善數據庫性能的一個不錯的策略。

　　第四層：數據庫對象。

　　若以上三個層面后，數據庫性能還不能夠得到大幅度改善的話，則就需要考慮是否能夠調整數據庫對象來完成我們的目的。雖然調整數據庫對象往往可以提到不錯的效果，但是，往往會對數據庫產生比較大的影響。所以，筆者一般不建議用戶一開始就通過調整數據庫對象來達到改善數據庫性能的目的。

　　數據庫對象有表、視圖、索引、關鍵字等等。我們也可以通過對這些對象進行調整以實現改善數據庫性能的目標。

　　如在視圖設計時，盡量把其顯示的內容縮小，寧可多增加視圖。如出貨明細表，銷售人員可能希望看到產品編號、產品中英文描述、產品名字、出貨日期、客戶編號、客戶名字等等。但是，對于財務來說，可能就不需要這么全的信息。他們只需要產品編號、客戶編號、出貨日期等等少量的信息即可。所以，能可浪費一點代碼的空間，設計兩張視圖，對應不同部門的需求。如此，財務部門在查詢數據時，不會為不必要的數據浪費寶貴的資源。

　　如可以通過合理設置索引來提高數據庫的性能。索引對于提高數據的查詢效率，有著非常好的效果。對一些需要重復查詢的數據、或者數據修改不怎么多的表設置索引，無疑是一個不錯的選擇。

　　另外，要慎用存儲過程。雖然說存儲過程可以幫助大家實現很多需求。但是，在萬不得已的情況下，不要使用存儲過程。而利用前臺的應用程序來實現需求。這主要是因為在通常情況下，前臺應用程序的執行效率往往比后臺數據庫存儲過程要高的多。

　　第五層：SQL 語句。

　　若以上各個層面你都努力過，但是還不滿足由此帶來的效果的話，則還有最后一招。通過對SQL語句進行優化，也可以達到改善數據庫性能的目的。

　　雖然說SQL Server服務器自身就帶有一個SQL語句優化器。他會對用戶的SQL語句進行調整、優化，以達到一個比較好的執行效果。但是，據筆者的了解，這個最多只能夠優化一些粗略的層面。或者說，80%的優化仍然需要數據庫管理員的配合。要數據庫管理員跟SQL優化器進行配合，才能夠起到非常明顯的作用。

　　不過，SQL語句的調整對于普通數據庫管理員來說，可能有一定的難度。除非受過專業的訓練，一般很難對SQL語句進行優化。還好筆者受過這方面的專業訓練，對這方面有比較深的認識。如在SQL語句中避免使用直接量。任何一個包含有直接量的SQL語句都不太可能被再次使用。我們數據庫管理員要學會利用主機變量來代替直接量。不然，這些不可再用的查詢語句將使得程序緩存被不可再用的SQL語句填滿。這都是平時工作中的一些小習慣。

　　總之，筆者認為，在數據庫性能調優的時候，若能夠遵循如上的順序，必定可以讓我們少走冤枉路，不花無用功。其實，數據庫調優并沒有我們想象的這么難。只要我們能夠掌握其中的訣竅，數據庫調優將可以手到擒來。