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