診斷Java代碼中常見的數據庫性能熱點問題(5)

　　進行大量更新操作的批處理作業的執行需要一段時間才能完成，尤其對于包含大量行的表來說更為明顯。如果整張表因此被鎖住，那么其他需要對這張表、哪怕只是對其中某些行進行更新的請求都必須等待鎖被釋放。你應考慮在沒有其他用戶在線的時間段運行這些作業，或實現某種不同的加鎖邏輯，實現對單個行的加鎖、更新以及釋放操作。

　　檢查點3：數據庫實例的運行狀態

　　在本文中，我著重分析的數據庫性能問題多數與數據庫服務器本身是否緩慢是無關的，而主要是由使用了糟糕的數據庫訪問模式(N+1次查詢問題、未經預處理的語句等等)的應用程序代碼、或是配置錯誤(低效的連接池訪問、數據驅動問題)所導致的問題。

　　但是，如果我們完全忽略了數據庫本身，那也是不明智的。因此，我總是會對關鍵的數據庫性能指標進行檢查。大多數數據庫都會通過特殊的系統表提供豐富的性能信息，比如Oracle就會提供某些v$表以及視圖，以訪問關鍵的數據庫性能指標(會話、等待時間、解析時間、執行時間等等)，或是表鎖以及運行時間較慢的SQL等信息，這些信息來自于使用這個共享的數據庫實例的各個應用程序。

　　我在進行數據庫健康檢查時通常會觀察兩個儀表板，你可以在此看到來自于這些性能表中的指標數據：

　　(點擊放大圖像)

　　觀察數據庫是處于健康狀態，還是由于共享該數據庫實例的應用產生過多的負載而產生了影響。

　　(點擊放大圖像)

　　通過表鎖等信息，判斷是否有某個正在執行中的SQL語句對服務器乃至你的應用造成了負面影響

　　在持續集成流程中對數據庫指標進行自動檢測

　　在我為你介紹分析關鍵數據庫指標以及用例的一些新點子之前，我希望首先能夠彌補一個缺失的主題，而這一點是我們都應當考慮到的，那就是自動化!

　　我建議你不要手動地執行這些檢查步驟，而是通過持續集成工具檢查這些指標，將這一步驟與單元測試、集成測試、REST API或其他類型的功能性測試等步驟結合在一起。如果你已經設計出一套測試用例集，用于檢查各種REST API或新特性的功能，那么為什么不在每次構建的測試執行期間去捕獲這些指標呢?這種方式可以帶來以下益處：

　　讓代碼評審過程專注于這些指標，而不是翻來覆去地閱讀每一行代碼

　　如果某個代碼簽入導致了這種問題，則發出通知

　　下面這幅屏幕截圖展示了每次構建與每次測試時對這些指標的追蹤，并在其表現異常時發出警告。你可以將這些指標集成在你的構建管道中，并且當某個代碼變更造成影響時通過通知信息了解情況，隨后立即修復這一問題，避免當代碼發布到生產環境時產生系統崩潰的情況。

　　(點擊放大圖像)

　　在你的持續集成流程中加入這些指標，并對指標的變化進行觀察，以自動地找出各種糟糕的數據庫訪問模式!

　　性能問題遠不止數據庫

　　在本文中，我們專注的是數據庫方面的熱點問題。但在我的工作過程中，我也在其他領域發現許多類型的性能問題。在2015年，我參與了一個將一體性應用遷移為(微)服務的項目，在其中發現了一個巨大的峰值問題。該問題類似于我們已分析過的某些模式，例如N+1次查詢問題，原因在于某個用例會數百次調用某個后端服務。大多數情況下，這種問題都是由糟糕的接口設計而造成的，并且沒有考慮到某個原本在本地調用的方法在Docker容器或云計算環境中被執行時會發生什么。網絡問題會突然間出現，包括通過網絡傳輸的信息以及新的連接池(意味著你需要考慮線程與套接字)，這些問題是你必須處理的。不過，這方面的內容已經超出了本文的范圍，請關注我們的后續文章。“愿指標與你同在” :-)

原文轉自：http://www.infoq.com/cn/articles/Diagnosing-Common-Java-Database-Performance-Hotspots