如何提高SQL Server資料庫的性能 該從哪裡入手呢?筆者認為 該遵循從外到內的順序 來改善資料庫的運行性能 如下圖
第一層 網路環境
到企業碰到資料庫反映速度比較慢時 首先想到的是是否是網路環境所造成的 而不是一開始就想著如何去提高資料庫的性能 這是很多資料庫管理員的一個誤區 因為當網路環境比較惡劣時 你就算再怎麼去改善資料庫性能 也是枉然
如以前有個客戶 向筆者反映資料庫響應時間比較長 讓筆者給他們一個提高資料庫性能的解決方案 那時 筆者感到很奇怪 因為據筆者所知 這家客戶資料庫的記錄量並不是很大 而且 他們配置的資料庫伺服器硬體很不錯 筆者為此還特意跑到他們企業去查看問題的原因 一看原來是網路環境所造成的 這家企業的客戶機有 多台 而且都是利用集線器進行連接 這就導致企業內部網路廣播泛濫 網路擁塞 而且由於沒有部署企業級的殺毒軟體 網路內部客戶機存在病毒 掠奪了一定的帶寬 不僅資料庫系統響應速度比較慢 而且其他應用軟體 如郵箱系統 速度也不理想
在這種情況下 即使再花十倍 百倍力氣去提升SQL Server資料庫的性能 也是竹籃子打水一場空 因為現在數據冊豎庫伺服器的性能瓶頸根本不在於資料庫本身 而在於企業的網路環境 若網路環境沒有得到有效改善 則SQL Server資料庫性能是提高不上去的
為此 筆者建議這家企業 想跟他們的網路管理員談談 看看如何改善企業的網路環境 減少廣播包和網路沖突;並且有效清除區域網內的病毒 木馬等等 三個月後 我再去回訪這家客戶的時候 他們反映資料庫性能有了很大的提高 而且其他應用軟體 性能也有所改善
所以 當企業遇到資料庫性能突然降低的時候 第一個反應就是查看網路環境 看看其實否有惡化 只有如此 才可以少走冤枉路
第二層 伺服器配置
這里指的伺服器配置 主要是講資料庫伺服器的硬體配置以及周邊配套 雖然說 提高資料庫的硬體配置 需要企業付出一定的代價 但是 這往往是一個比較簡便的方法 比起優化SQL語句來說 其要簡單的多
如企業可以通過增加硬碟的數量來改善資料庫的性能 在實際工作中 硬碟輸入輸出瓶頸經常被資料庫管理員所忽視 其實 到並發訪問比較多的時候 硬碟輸入輸出往往是資料庫性能的一個主要瓶頸之一 此時 若資料庫管理員可以增加幾個硬碟 通過磁碟陣列來分散磁碟的壓力 無疑是提高資料庫性能的一個捷徑
如增加伺服器的內存或者CPU 當資料庫管理員發現資料庫性能的不理想是由內存或者CPU所造成的 此時 任何的改善資料庫伺服器本身的措施都將一物用處 所以 有些資料庫管理專家 把改善伺服器配置當作敗姿亂資料庫性能調整的一個先決條件
如解決部署在同一個資料庫伺服器上的資源爭用問題 雖然我們多次強調 要為資料庫專門部署一個伺服器 但是 不少企業為了降低信息化的成本 往往把資料庫伺服器跟應用伺服器放在同一個伺服器中 這就會導致不同伺服器之間的資源爭用問題 如把文件伺服器跟數據伺服器部署在同一個伺服器中 當對文件伺服器進行備份時 資料庫性能就會有明顯的下降 所以 在資料庫性能發現周期性的變化時 就要考慮是否因為伺服器上不同應用對資源的爭奪所造成的
故 筆者建察檔議 改善資料庫性能時第二個需要考慮的層面 就是要看看能否通過改善伺服器的配置來實現
第三層 資料庫伺服器
當通過改善網路環境或者提高伺服器配置 都無法達到改善資料庫性能的目的時 接下去就需要考察資料庫伺服器本身了 首先 就需要考慮資料庫伺服器的配置
一方面 要考慮資料庫伺服器的連接模式 SQL Server資料庫提供了很多的資料庫模式 不同的資料庫連接模式對應不同的應用 若資料庫管理員能夠熟悉企業自身的應用 並且選擇合適的連接模式 這往往能夠達到改善資料庫性能的目的
其次 合理配置資料庫伺服器的相關作業 如出於安全的需要 資料庫管理員往往需要對資料庫進行備份 那麼 備份的作業放在什麼時候合適呢?當然 放在夜晚 夜深人靜的時候 對資料庫進行備份最好 另外 對於大型資料庫 每天都進行完全備份將會是一件相當累人的事情 雖然累得不是我們 可是資料庫伺服器也會吃不消 差異備份跟完全備份結合將是改善資料庫性能的一個不錯的策略
第四層 資料庫對象
若以上三個層面後 資料庫性能還不能夠得到大幅度改善的話 則就需要考慮是否能夠調整資料庫對象來完成我們的目的 雖然調整資料庫對象往往可以提到不錯的效果 但是 往往會對資料庫產生比較大的影響 所以 筆者一般不建議用戶一開始就通過調整資料庫對象來達到改善資料庫性能的目的
資料庫對象有表 視圖 索引 關鍵字等等 我們也可以通過對這些對象進行調整以實現改善資料庫性能的目標
如在視圖設計時 盡量把其顯示的內容縮小 寧可多增加視圖 如出貨明細表 銷售人員可能希望看到產品編號 產品中英文描述 產品名字 出貨日期 客戶編號 客戶名字等等 但是 對於財務來說 可能就不需要這么全的信息 他們只需要產品編號 客戶編號 出貨日期等等少量的信息即可 所以 能可浪費一點代碼的空間 設計兩張視圖 對應不同部門的需求 如此 財務部門在查詢數據時 不會為不必要的數據浪費寶貴的資源
如可以通過合理設置索引來提高資料庫的性能 索引對於提高數據的查詢效率 有著非常好的效果 對一些需要重復查詢的數據 或者數據修改不怎麼多的表設置索引 無疑是一個不錯的選擇
另外 要慎用存儲過程 雖然說存儲過程可以幫助大家實現很多需求 但是 在萬不得已的情況下 不要使用存儲過程 而利用前台的應用程序來實現需求 這主要是因為在通常情況下 前台應用程序的執行效率往往比後台資料庫存儲過程要高的多
第五層 SQL 語句
若以上各個層面你都努力過 但是還不滿足由此帶來的效果的話 則還有最後一招 通過對SQL語句進行優化 也可以達到改善資料庫性能的目的
雖然說SQL Server伺服器自身就帶有一個SQL語句優化器 他會對用戶的SQL語句進行調整 優化 以達到一個比較好的執行效果 但是 據筆者的了解 這個最多隻能夠優化一些粗略的層面 或者說 %的優化仍然需要資料庫管理員的配合 要資料庫管理員跟SQL優化器進行配合 才能夠起到非常明顯的作用
不過 SQL語句的調整對於普通資料庫管理員來說 可能有一定的難度 除非受過專業的訓練 一般很難對SQL語句進行優化 還好筆者受過這方面的專業訓練 對這方面有比較深的認識 如在SQL語句中避免使用直接量 任何一個包含有直接量的SQL語句都不太可能被再次使用 我們資料庫管理員要學會利用主機變數來代替直接量 不然 這些不可再用的查詢語句將使得程序緩存被不可再用的SQL語句填滿 這都是平時工作中的一些小習慣
lishixin/Article/program/SQLServer/201311/22452
⑵ 如何提高sql語句的執行效率
1、使用ordered提示
Oracle必須花費大量的時間來剖析多表的合並，用以確定表合並的最佳順序。SQL表達式涉及七個乃至更多的表合並，那麼有時就會需要超過30分鍾的時間來剖析，Ordered這個提示(hint)和其他的提示一起使用能夠產生合適的合並順序。
2、使用ordered_predicates
ordered_predicates提示在查詢的WHERE子句里指定的，並被用來指定布爾判斷(Booleanpredicate)被評估的順序。在沒有ordered_predicates的情況下，Oracle會使用下面這些步驟來評估SQL判斷的順序：子查詢的評估先於外層WHERE子句里的Boolean條件。
所有沒有內置函數或者子查詢的布爾條件都按照其在WHERE子句里相反的順序進行評估，即最後一條判斷最先被評估。每個判斷都帶有內置函數的布爾判斷都依據其預計的評估值按遞增排列。
3、限製表格合並評估的數量
提高SQL剖析性能的最後一種方法是強製取代Oracle的一個參數，這個參數控制著在評估一個查詢的時候，基於消耗的優化器所評估的可能合並數量。
(2)sql怎麼提高提點擴展閱讀：
1、表設計的優化，數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、語句的查詢優化，保證在實現功能的基礎上，盡量減少對資料庫的訪問次數；
3、建立高效的索引創建索引一般有以下兩個目的：維護被索引列的唯一性和提供快速訪問表中數據的策略。
大型資料庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構存儲數據，所有的數據均添加在表的尾部，而建立了簇索引的表，其數據在物理上會按照簇索引鍵的順序存儲。個表只允許有一個簇索引。
4、強制查詢轉換，有時候oracle 的優化器未必能走正確的查詢路線，這個時候就需要添加一些hint 之類的來規定他的執行路線。當然了，這個未必是最好的處理方案。因為雖然現在走這個路線是對的，以為因為數據的變化到這這個HINT 變得不可取。
⑶ 如何提高sql資料庫的查詢速度
一、程序中：
1、保證在實現功能的基礎上，盡量減少對資料庫的訪問次數。
2、通過搜索參數，盡量減少對表的訪問行數,最小化結果集，從而減輕網路負擔，能夠分開的操作盡量分襲蔽開處理，提高每次的響應速度。
3、在數據窗口使用SQL時，盡量把使用的索引放在選擇的首列，演算法的結構盡量簡單。
二、避免使用不兼容的數據類型。
例如「float」、「int」、「char」等，都屬於不兼容。 數據類型的不兼容可能使優化器無法執行一些本來可以進行的優化操型態作。
三、盡量避免在Where子句中對欄位進行函數或表達式卜禪源操作，這將導致引擎放棄使用索引而進行全表掃描。
四、盡量使用數字型欄位。
一部分開發人員和資料庫管理人員喜歡把包含數值信息的欄位設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。