問答專欄Q & A COLUMN
我是【會點代碼的大叔】，每天為你分享程序員干貨，關注并私信我數字“1”，送你一份程序員大禮包。
MySQL 數據庫某張表近千萬的數據，CRUD比較慢，如何優化？
說實話，這個數據量級， MySQL 單庫單表支撐起來完全沒有問題的，所以首先還是考慮數據庫本身的優化。
從上圖可以看到，數據庫優化通常可以通過以上幾點來實現：
對于開發人員來說，我們需要把注意力放在后面三點：
優化 SQL 語句執行速度的方法有很多，比如：
說完了 MySQL 本身的優化，如果數據量進一步增大的話，我們還有什么優化的方案呢？
主庫用于寫，從庫用于讀，將讀寫分散在不同的數據庫上，利用多臺機器的資源，來提高數據庫的可用性和性能。
如果數據持續增多，超過了單臺 MySQL 的支撐上限，那么只能用【分庫分表】這一招了；我們可以采用一定的路由規則，將數據保存到不同的數據庫中。
當然，如果不是“迫不得已”，我是不太建議分庫分表的，因為這樣極大地增加了系統的復雜程度，并且會帶來更多的問題需要開發人員解決。
以上就是常用的 MySQL 優化方案，如果是千萬級數據量，優化 MySQL 本身即可。
評論0
加載中...
MySQL 數據庫某張表近千萬的數據，CRUD比較慢，如何優化？最常見的是線程池優化、索引優化、緩存優化、讀寫分離、數據庫拆分等，上述4種優化可以從不同角度來優化我們的數據庫操作，其中的可操作性性要看團隊的技術能力和應用的維護能力，我就以自己遇到過的應用場景簡單談談自己的優化流程。
換到新的團隊，遇到的第一個棘手問題就是數據庫不定時的出現“Cannot get a connection, pool error Timeout waiting for idle object”，經和DBA溝通，其反饋數據庫group（數據庫量級4kw+）中的查詢邏輯很多，qps達1w+，并且慢sql積壓，拖垮了數據庫。從慢sql和上述查詢異常著手，進行千萬級的數據庫優化。
1. 線程池優化。線上的讀線程池16，寫線程池池16，考慮到數據查詢時獲取不到數據庫連接，將讀線程池調整為32，其優化效果不明顯，數據庫建立連接的異常仍然存在。
2.索引優化。經和DBA分析相關的慢sql語句，發現其索引都是完備的，也就是說每個查詢都可以落到對應的索引邏輯，這點兒我們心里是有數的，畢竟線上正常運行了2年多數據庫，當時建庫和查詢時肯定考慮到了索引的情況。也就是說，在這方面沒有優化的余地。
3.緩存優化。經排查，線上的相關操作采用緩存加速，緩存時間1h或24h不等，考慮到數據庫瓶頸和更新數據刪緩存的邏輯，將緩存時間延長至7天。該優化邏輯上線后，數據庫異常有所減弱，但問題仍未解決。偶爾發現，客戶端偶爾會請求服務端不存在的數據，引發緩存穿透。而針對該庫涉及到的可能存在緩存穿透的邏輯，進行了一系列優化。優化之后，效果特別明顯，也就是在線上業務達到一定量級時，要特別注意緩存穿透，這點在業務剛開始時很容易被忽略。
4.讀寫分離。雖然通過緩存穿透的優化處理，解決了數據庫連接異常的問題，但是讀寫分離仍然值得嘗試，讀寫分離是應對讀多寫少業務的一大利器，一主多從的讀寫分離模式被引入彈性數據庫體系，讓我們在特殊節點的業務保障更有信心。
5.數據庫拆分，也就是分庫分表。業務發展到一定程度，分庫分表是優化的必經之路，也是我們團隊一項很重要的優化業務，但限于業務場景、分庫分表規則、多維度查詢、團隊研發資源等，目前正在規劃中。
綜上所述，通過優化緩存穿透和讀寫分離解決了我們線上業務的數據庫性能問題，可操作性強，風險相對降低。
作者：夕陽雨晴，歡迎關注我的頭條號：偶爾美文，主流Java，為你講述不一樣的碼農生活。
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
