? ? ? ?先簡單介紹下博主 面臨的情況，17年底，一個用了5年的售后系統處于要升級換代又因為其他原因導致暫時不能升級的情況，所以需要在不動大的架構的情況來做優化。具體有個呼叫中心，坐席會一直在接電話，60人左右，電話保存時有個很復雜的派單邏輯，要優先保證效率。外面管理員，維修工，操作員3000+。

? ? ? ?先用代碼整理下，看看各個表都是多大

--Script1: --查看某數據庫所有表的信息 DECLARE @tablespaceinfo TABLE ([name] SYSNAME,[rows] BIGINT,[reserved] VARCHAR(100),[data] VARCHAR(100),[index_size] VARCHAR(100),[unused] VARCHAR(100) )DECLARE @tablename VARCHAR(255);DECLARE Info_cursor CURSOR FORSELECT '['+[name]+']' FROM sys.tables WHERE TYPE='U';OPEN Info_cursor FETCH NEXT FROM Info_cursor INTO @tablenameWHILE @@FETCH_STATUS = 0 BEGININSERT INTO @tablespaceinfo EXEC sp_spaceused @tablenameFETCH NEXT FROM Info_cursor INTO @tablename ENDCLOSE Info_cursor DEALLOCATE Info_cursorSELECT * FROM @tablespaceinfoORDER BY Cast(Replace(reserved,'KB','') AS INT) DESC

復制下來直接執行就好，結果是數據庫大致400G,最大的表為客戶檔案和客戶資產，分別有2000萬條和1800萬條數據這兩個數據表，之前優化后已經對表做了分區，具體可以看表分區，下面是要先對呼叫中心反映的卡頓做對應的處理，說是電話接入后要10-20秒才會有反應，需要出畫面打開慢的原因。

開始以為是兩個大表的原因，后面發現不是，下面介紹下最快速發現問題的工具。

框框中標識的是活動監視器，里面會有幾個非常有用的東西，我們繼續暫開說

活動監視器會自動給出這些監視的內容，這里有兩點非常需要關注，最近耗費大量資源的查詢，以及進程。雙擊這些查詢最近耗費大量資源的查詢，會看到具體的語句。我們這時只要在其中發現我們需要優化的界面中存在的語句調用的內容，就可以做對應處理。同時插一句，如果讓這里耗費大量資源語句的都得到優化就已經極大的完成了任務了。

這個是我找出來的問題的存儲過程，發現這個執行起來非常慢大概需要15秒，雖然看著表很多，但總覺得不至于。圖中可以發現，有大量的DATEADD(MM,-6,GETDATE())為了獲取最近6個月的服務數據，那就簡單了，創建個變量代替這個就行。現在這個存儲過程被壓縮到2秒，另外說一句，就算不用運算getdate這個函數，取一次，然后用變量代替getdate也會比現在優化很多，不需要反復去數據庫取時間。

下面是進程

這是當時上線一個外部app端后的情況，可以發現目前的資源等待已經很嚴重了，高達8517毫秒，雖然阻塞者都是自己273，但其實是有很多可以優化的空間的。雙擊，可以看到詳細的回話信息，里面的內容可以拷出來單獨優化。語句中有個*非常的扎眼，這里說下當你想在select子句中列出所有的列時，使用動態sql列引用“*”是一個方便的方法，不幸的是，是一種非常低效的方法。sql解析過程中，還需要把“*”依次轉換為所有的列名，這個工作需要查詢數據字典完成！后續查看該視圖，又將里面的UNION ALL拆分，將該語句效率提升了3倍左右。

在最下方還有個SELECT? COUNT (*) from的語句，可能這是學校里教法，但實際應用中把count（*）換成count（1）在改語句中竟然可以提升60%的效率，親測有效。

最后帶一下概述

這里的計數器是反應服務器性能的，如果其他方面沒用，只能通過提升硬件了。挑選服務器已經在前面提過。

在這問題優化過后，數據庫還經歷了很多事務方面的優化，打算在后面單獨講，包括臟讀幻讀需要的注意點，性能和準確性的兼顧，這些都是需要統籌考慮的。活動監視器這個sql的神器，希望可以得到更改的應用，幫到大家，一般小問題都可以比較簡單的從這里面發現

經過1個月的優化，這套服務了5年的系統終于繼續愉快的跑了起來。對于一個服務了這么多年系統，真不容易哦。

總結

以上是生活随笔為你收集整理的数据库优化的方法及步骤的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。