|
性能問題是困擾數據庫用戶的常見問題之一,。經常會有人因為遇到性能問題,，質疑SQL Server處理大型數據應用的能力。其實,，作為一個在市場上經營了二十多年,，出了好幾代版本的數據庫產品，SQL Server作為一個企業(yè)級數據庫的能力,，是毋庸置疑的,。在實際應用中，數據量達到幾百GB,，甚至上TB級,，并發(fā)連接數超過1、2千個,，每秒鐘處理的請求 數量超過1000多個的SQL Server,，現(xiàn)在已經很多了,。在國內的一些大客戶那里，我們也越來越多地看到這樣的SQL Server,。 那為什么有些SQL Server能跑得那么強勁,，而很多用戶的數據庫還只有幾十GB，就感覺跑不動了呢,？在談性能問題的常見原因之前,，我們先談談SQL Server的幾個和性能有關的重要特性。了解這些特性,，對設計一個高效的數據庫應用,，是非常必要的。 1. SQL Server要訪問的數據,，是一定要緩沖在內存里的不管是要查詢的數據,，還是要修改的數據，SQL Server在運行客戶端發(fā)過來的語句,，處理這些數據之前，都要檢查其訪問的數據是否在內存中,。如果不在內存中,，SQL Server會先把存儲數據的頁面從磁盤調入內存，然后再做真正的數據處理,。 數據處理完畢后,，SQL Server不會馬上把這段數據緩存丟棄。只要SQL Server不缺內存,，先前訪問過數據頁面就會一直緩存在SQL 這樣的設計,，可以最大程度的重用內存,，提高SQL Server的處理速度。同時也決定了,，SQL Server是一個非常喜歡大內存的應用程序,。 2. 如果SQL Server沒有空閑的內存，而用戶需要訪問新的數據,，SQL會把以前緩存的數據挑選一部分從內存中清除,，騰出空間來緩存新的數據SQL Server不會無限制地申請內存。它會根據用戶的設置,，以及系統(tǒng)的內存數量,，計算自己的最大內存數。如果當前的內存大小以及達到了這個上限，SQL就不 會再向Windows申請更多的內存,。這樣的機理,，可以保證SQL Server和Windows，以及運行在同一臺機器上的其他應用程序和平共處,。 當SQL Server的內存數已經達到最大值,，內存空間已經緩存滿各種各樣的數據頁面，而用戶又要訪問新的,、還沒有緩存在內存里的數據時,，SQL 所以最理想的狀態(tài),，是用戶要訪問的數據永遠都緩存在內存里，SQL Server從來都不需要到磁盤上去找,。這也是數據庫性能最佳的情況,。這時候SQL Server幾乎從來不需要做磁盤讀。 如果經常發(fā)生用戶要訪問的數據不在內存里的情況,，SQL Server就會被迫不停地在內存和磁盤之間倒騰數據,，性能會受到嚴重的影響。而這時候,，你會看到SQL在經常地作磁盤讀的動作,。 3. 表格中數據的組織與訪問，和聚集索引的選擇密切相關SQL Server的一個顯著的特點,，是表格里數據的存儲,，是按照聚集索引所在字段的值排序的。而非聚集索引是建立在聚集索引結構之上的,。如果一張表格沒有聚集索引,，數據是按照堆的方式存儲，沒有任何順序,。 對于同樣的數據量,，SQL Server對一個有聚集索引的表格的管理，遠遠比沒有聚集索引的表格要有效,。絕大多數情況下,，一張大表如果想要有良好的性能，就必須有一個合適的聚集索引,。沒有聚集索引,，只加非聚集索引,，也不能夠達到優(yōu)化的性能。 這是SQL Server的一個很重要的特點,。 4. 在缺省的事務隔離級別下,，同一條記錄上的讀操作和寫操作是互斥的SQL Server實現(xiàn)的是ANSI 標準的四個隔離級別。在Read Committed這個缺省的隔離級別上,，讀操作會申請S鎖,，修改操作會申請X鎖，S鎖和X鎖互斥,。所以同一條記錄上不能同時進行讀操作和寫操作,。 業(yè)界的有些其他數據庫產品，缺省使用行版本控制方式實現(xiàn)事務隔離,，如果一個用戶在修改某一條記錄,、但是沒有提交事務，而另一個用戶要讀同一條記錄,，它會讓第二個用戶讀到第一個人修改之前這條記錄的值,。所以讀操作和寫操作是可以同時進行的。 這種版本控制的隔離級別,，并發(fā)度當然比SQL Server的要高,，讀寫操作之間產生阻塞的幾率要小?？墒撬氖聞崭綦x效果和SQL是不同的。例如,，對于某個銀行賬戶的查詢,，假設賬戶里原來有1萬元， 用戶A開始一個事務,，將賬戶里的1萬元轉出,。在轉出這個動作還沒有完成時，用戶B來查詢賬戶余額,。使用版本控制,，用戶B可以馬上得到結果：1萬元，但是這 個結果其實很有可能已經過時,。使用SQL Server,，用戶B必須等到用戶A轉帳完成才能查到余額，但是他得到的一定是一個最新的值,。 這兩種隔離級別其實反映了兩種用戶需求,，不能講哪種好，哪種不好,。喜歡版本控制這種隔離級別的用戶,，如果想要在SQL 上面的這幾個特征，決定了SQL Server的很多???為特點,。如果跑在SQL Server上應用程序沒有很好地按照上述的特征設計,，就容易遇到各種各樣的性能問題。 在現(xiàn)實應用中,，SQL Server性能問題的常見原因有下面幾點,。 1. 索引的設計不夠優(yōu)化，從而迫使語句經常使用全表掃描的執(zhí)行計劃如果沒有好的索引幫助,，SQL Server查詢任何一條記錄都有可能不得不把整張表都掃描一遍,。這個在數據庫比較小的時候影響不大，因為SQL能夠把所有數據都緩存在內存里,，就算是全 表掃描也不會太慢,。隨著數據量增大，內存會放不下,。全表掃描的負擔會越來越重,，到最后會嚴重影響SQL 這是一個很常見的SQL Server越跑越慢的原因,。 2. 大的表格沒有聚集索引,，或者聚集索引建立在不合適的數據列上對于沒有聚集索引的表格，如果里面的記錄數以萬計或者更多,，管理和查詢都會增加很多開銷,。一個經驗是，對于一個要經常使用的任何大表格,，請建立聚集索引,。索引所在的數據列，應該是一個或者幾個重復性的記錄不是很多的數據列,。 業(yè)界的一些其他數據庫可能對聚集索引這個概念不是非常強調,，或者使用其他的方法管理表格。所以如果把非SQL 3. 用戶需要經常訪問的數據量,，遠大于機器的內存數前面我們已經說過,，SQL 用戶需要經常訪問的數據量的大小，通常跟以下幾個因素有關,。 a.用戶發(fā)過來的語句定義 如果語句里有良好的條件約束,，那數據量就能得到控制。如果條件約束性不強,，那數據量就會隨著表格里的記 錄數增長而增長,。一個例子是，用戶總是查詢“今年的某某數據”,。那在一年開始的時候,，查詢肯定很快。到年底時候的數據量可是一月份的12倍,。那時候訪問的 數據量也很可能就是12倍,。 b.SQL Server是否能夠利用索引，使用Seek的方式找到數據,，而不是掃描全表 如果沒有好的索引,，哪怕用戶要訪問的數據只是表格里的很小一部分，SQL可能也需要遍歷整個表格,。在這種情況下,，也會出現(xiàn)表格越大，SQL跑得越慢的情況,。如果索引設計地比較優(yōu)化，SQL Server的數據訪問量,，不應該跟表格的大小有著絕對的關系,。 c.應用程序的性質 數據庫應用基本可以分兩大類：OLTP類型的，和Data Warehouse類型的,。前者會處理大量的小事務,，比如病人掛號、超市結帳,、倉庫進貨等,。這種應用用戶發(fā)過來的請求不會很復雜，每次要處理的數據量也比 較小,，但是要求的響應速度要很快,。有可能0.5秒的等待都會帶來性能問題,。所以對這種應用，其訪問的數據應該保證總是緩存在內存里,。 Data Warehouse類型的應用主要是做數據分析和整理,，經常是為了產生一些報表。這種應用主要以查詢?yōu)橹?，肯定會訪問大量的數據,，會出現(xiàn)數據庫越大，訪問的數據量越多的情況,。但是客戶端可以容忍一定時間的等待,。對于這種應用，其訪問的數據不在內存里關系也不大,。 對于OLTP類型的應用,，應該盡量保證用戶經常要訪問的數據能夠長時間地緩存在內存里。所以在設計應用邏輯和數據庫時,，就要有所考慮,，控制用戶訪問 的數據量，建立有效的索引,，避免全表掃描,。在管理上，也要有歷史數據歸檔的機制,，控制整個數據庫的大小,。如果證明用戶需要訪問的數據量就是比內存大，升級 內存也是需要考慮的方案,。 對于報表類型的應用,，因為訪問的數據量會很大，磁盤換頁是難以避免的,。當然良好的索引設計,，對性能也會很有幫助。 要避免的情況,，是同一個SQL Server既在運行OLTP類型的應用,，又時不時地在運行報表類型的應用。它們兩者會產生很大的相互干擾,，對OLTP應用的響應速度會產生破壞性的影響,，而且很難用調整數據庫設計，或者升級硬件的方法輕易解決,。 4. 數據庫應用是從其他非SQL Server的架構下直接移植過來的前面已經談過,，SQL Server缺省的事務隔離級別是Read Committed，和其他數據庫可能不一樣,。另外,，很多應用是通過調用數據庫控件的接口來訪問數據庫的,，而不是直接調用SQL語句或者存儲過程。要達到 同一個目的,，程序里有很多種實現(xiàn)的方法,。有些方法可能在其他數據庫上性能會不錯，但是到SQL |
|
|
