如何使 SQL Server高效 — 疑難（ITPUT 討論匯總）

4、     在您的SQL Server使用過程中，有哪些令您非常困惑的效能問題 ?

討論匯總——綜合

l  Tempdb方面的問題

a）  行級和事務級的快照都儲存在TEMPDB中 (不知架構為什麼設計成這樣),UNDO \ REDO 自然不太方便

b）  tempdb放了太多的功能，帶來效能瓶頸

個人觀點： tempdb感覺確實是個瓶頸。每個版本幾乎都會往tempdb裡面多放一些東西，tempdb所承擔的東西是越來越多

l  配置方面的問題

a）  DBA調整方面能夠做的事情不多，記憶體調整隻有2個參數

b）  I/O調整，除了檔案級的分離，DBA還能做哪些事情

c）  似乎MSSQL DBA能夠做的效能調整就是維護計劃，索引最佳化和統計資訊 磁碟重組，SQL語句層級調整

d）  記憶體方面，可控性太少了，划了塊大記憶體後，其他的DBA都幹不了了

e）  效能調整方面。MSSQL給DBA的空間比較小

個人觀點： 配置參數的多少這個不太好說，SQL Server還有不少配置項是沒有在官方文檔上公開說明的；在實際應用中，感覺基本上需要調整的配置項不是太多，不做配置也基本上能夠適應大部分情況（自動設定方面做得還是不錯）；至於DBA的日常工作，只要能夠使用合適的方法保障伺服器的效能和穩定，並且有合適的措施去預防重複故障的發生就基本達到目標了。至於DB方面是否提供了對應的支援，這個只能具體問題具體分析，有可能是沒有提供，也有可能是你沒有找到

l  負載平衡。貌似SQLServer上沒什麼好的方案吧

個人觀點：Always on應該算是邁進了一大步，但確實是沒有完備的方案

l  DB LINK，貌似不會走索引，在涉及跨庫的時候大資料時，比較糾結

個人觀點：會走索引，但限制性比執行個體內要高；在執行個體內，查詢最佳化工具會儘可能解析對象到基礎對象，並擷取得評估查詢成本相關的資訊；對 DB lINK，其擷取查詢成本評估資訊的對象就是查詢的對象，如果查詢的是表，自然可以擷取到相碰的資訊，如果不是非索引檢視表，則是沒有索引、統計資訊這類對查詢成本評估很有協助的資訊可擷取，自然就無法走索引

l  生產環境鏡像與複製並存，而mirror的效能似乎不高，經常出現延遲現象，查看wait event，總是鏡像方面的等待事件佔多

個人觀點：可以通過鏡像監視器或者鏡像相關的動態視圖、效能指標，進一步確定延遲的點，以確定可行的改進

l  千萬級大表的排序彙總操作效能尤其低，這方面最佳化比較困難，目前除了合理索引，大表分區和讀寫分離建立獨立的report server外，沒有更好的方法

個人觀點：大量資料的彙總應該是要在常規查詢中避免的，比如你可以用Job定時把把曆史資料彙總寫入到彙總表，這樣查詢只需要彙總未彙總的部分，再UNIONALL已經彙總的資料就可以了；建立包含彙總資料的索引檢視表，也是一個可行的解決方案（對資料的變更效率會有一定的影響）。另外，通常應該考慮將OLTP和OLAP任務分離

l  發布訂閱大並發。大DML量很容易導致死結，簡單的讀寫分離是我多年心頭的痛

個人觀點：包含發布的資料庫，如果短時間內有表做過大量的資料變更，確實會導致一些問題。複製的日誌讀取器需要花大量時間去讀出這些日誌，並提取和產生需要發布的命令；如果被更改的是發布的表，並且分發與發布是共用一個執行個體的話，分發的壓力也會對伺服器造成壓力；而且複製的命令是記錄級（行級）的，所以大量的資料變更的同步周期也會比較長。對於大量資料變更，在可行的情況下，可以考慮勇冠複製預存程序的方式來解決；如果資料變更已經執行，重新同步那些產生了巨大資料變化的表可能是一個解決問題的方法

l  以前遇到一個情況是，加上forceorder後1秒內出結果；去掉force order要15秒

個人觀點：可能是統計資訊不準，或者是條件包含像變數這種無法確定值的情況，導致查詢最佳化工具評估的成本不準

l  一個SQL的Instance下，資料庫不斷在增加，每個資料庫都不太大……長期下去3000個資料庫都估計達到的情況下，會不會有效能瓶頸？

個人觀點：容易出來效能瓶頸，最常見的可能會是tempdb資源的銀用，畢竟每個執行個體只有一個tempdb，而且很多內部的東東都或多或少會用到tempdb；第2個可能會爭用的資源可能是串連資源；另外，管理上可能也會受到影響，比如Job、Login可能會多而且不太容易管理

l  往往查詢最多的表，就是更新最頻繁的表。更新最多的欄位，也是查詢最多的欄位。典型的例子是訂單表。訂單表在不斷insert，訂單狀態欄位在不斷update。另一方面，訂單表在不斷被查詢，例如當前日期下，已下單未發貨的訂單詳情，已發貨未付款的訂單詳情等等，我們的系統裡，這個訂單查詢介面，都是只要它被開啟，就有線程每5秒鐘重新整理一次最新訂單狀況。注意每一個用戶端每5秒重新整理一次。同時線上的使用者如果上千個，等於這個表每秒都在重新整理了。請問這種情形，大家有什麼好的建議？

個人觀點：考慮讀寫分離。另外，考慮程式設計是否合理，比如5秒釧重新整理一次的頻率是為了100%滿足使用者需求，1分鐘重新整理一次是否可以滿足90%的需求，如果可以的話，是否一定要滿足到100%？手段上，DB資料重新整理訪問是否可以由一個服務統一控制？如果在同一時間有5個用戶端調用這個服務，那麼服務只需要取一次資料，分發給5個用戶端就行，沒必要每個用戶端獨立去訪問DB；更進一步的，是否可以為資料變更設定標誌，使用增量的拉資料的方式？

l  在對很大的表做分區merge操作或者重建索引時, 伺服器的cpu使用率很低,，而從sysprocesses中查詢到進程的等待類型又是 sos_scheduler_yield，不理解為什麼會這樣.

個人觀點：可以看看各個CPU的任務分配，看是否是因為分配差異太大導致（某一兩個CPU使用率高，其他空閑）SELECT scheduler_id , current_tasks_count, runnable_tasks_countFROM sys.dm_os_schedulers WHERE scheduler_id < 255

l  其他一些SQLserver的時候困擾的因素包括

a）  新版耗記憶體,CPU處理能力跟不上，磁碟不夠大，使得原來舊裝置效能到了瓶頸，結果只有一個：退役，更換裝置，導致成本增加，裝置不能更好的合理利用

b）  新版sqlserver雖然增加了列索引，但也存在索引效能的瓶頸

c）  資料庫作業效能瓶頸

d）  低效率的SQL語句導致資料庫整體效能降低

e）  T-SQL效能的瓶頸

f）  高並發，需求不穩定，突兀的穀峰交易對資料庫和應用的衝擊最大

g）  CPU佔用率高的現象比較多，降低了又會上去

個人觀點：新的東西確實會對硬體有更新的要求，畢竟其設計基礎與舊版本是不一樣的，根據需要選擇合適的版本即可，並不是最新的就一定是最適合的。效能問題，需要一個跟蹤分析的過程，確定清楚原因才能找到有效解決方案

 

討論帖 之前的討論話題：1、 您認為在設計SQL Server對象時，主要會考慮哪些因素來避免出現效能問題? 2、 您認為在T-SQL編寫（包括預存程序、函數和視圖）上，哪些因素會影響SQL Server效率?3、 在設計資料庫操作程式上，您認為應該注意哪些事項，以確保能夠有效地使用資料庫?