這段時間做一個SQL效能優化的案例分析， 整理了一下過往的案例，發現一個比較有意思的，拿出來給大家分享。
這個專案是我在專案開展2期的時候才加入的， 之前一期是個金融內部資訊門戶， 裡面有個功能是收集各個上市公司的財報， 然後做各種分析， 資料圖表展示， 使用的人數並不多， 僅百人左右。
2期打算面向行外使用者， 剛開始預計同時線上人數不超過50, 就以50訪問使用者/秒的效能測試， 結果在把1期的圖表類資料展示響應基本在5分鐘左右， 屬於嚴重不可用， 說說我們的伺服器配置， 有2臺網站前端承載使用者訪問， 做F5負載均衡， 也就是說一臺約25使用者/秒的訪問量， 有2臺資料庫做AlwaysOn。通過程式碼斷點跟蹤很快確定了效能瓶頸在資料庫響應這一層。
既然確定了是資料庫的效能問題， 接下來我們就準備開始對伺服器的效能進行跟蹤， 我們選取了常用的效能指標(記憶體，CPU，網路，硬碟IO)進行跟蹤，然後跑我們的效能測試。
結果顯示， CPU基本在測試的過程中是100%, 記憶體也佔用了98%, 資料庫硬碟IO的響應時間也超過了2分鐘，記憶體指標是正常的， 由此我們可以得出幾個假設:
資料庫在不斷進行TSQL語句編譯，在高併發的情況下可能造成CPU佔用率一直很高。
資料庫有索引查詢需要優化。
資料可能存在死鎖
確實存在一些表存在大量資料的情況
事實上我們檢查到程式設計師在編寫程式碼的時候， 並沒有利用到正確使用資料庫變數，而是動態的生成T-SQL語句， 導致在高併發的時候， 頻繁的進行語句編譯，這印證了我們的第一點。
再進一步的我們通過Profiler工具找到響應時間較長的語句進行分析， 檢視實際的執行計劃， 優化了查詢條件， 增加了索引，及查詢條件優化
令我們意外的發現，是在某一時刻，進行簡單的一個表進行查詢， 也會長達數十分鐘之久， 執行EXECUTE sp_lock， 查到其中一個應用程式正在使用insert into select from 批量插入資料到這一表中， 造成這一表讀被鎖定， 改用bulk insert解決了問題
1期也使用了一年中， 其實一些表的資料確實也已達到上億的級別， 考慮到資料圖表展示都是以一個月的資料為單位， 我們對這個表的資料進行了分割槽， 每個月的資料以單獨的資料檔案進行儲存，實際上也取得了很好的效果。
最後在效能測試中， 我們的響應時間從原來的5分鐘減少到2秒內， 符合了我們需要。