這段時間做一個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秒內， 符合了我們需要。?

?

轉載于:https://www.cnblogs.com/frankzye/p/5808909.html

總結

以上是生活随笔為你收集整理的SQL性能优化案例分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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