我是【會點代碼的大叔】，每天為你分享程序員干貨，關(guān)注并私信我數(shù)字“1”，送你一份程序員大禮包。
MySQL 數(shù)據(jù)庫某張表近千萬的數(shù)據(jù)，CRUD比較慢，如何優(yōu)化？ 說實話，這個數(shù)據(jù)量級， MySQL 單庫單表支撐起來完全沒有問題的，所以首先還是考慮數(shù)據(jù)庫本身的優(yōu)化。  從上圖可以看到，數(shù)據(jù)庫優(yōu)化通?？梢酝ㄟ^以上幾點來實現(xiàn)： - 硬件升級：也就是花更多的錢，升級我們數(shù)據(jù)庫硬件配置，包括 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等等，但是這個方案成本高，而且不一定能起到非常好的效果。
- 數(shù)據(jù)庫配置：修改數(shù)據(jù)庫的配置，有可能讓我們的 CRUD 操作變得更快，不過我也不建議大家把經(jīng)歷放在這一點上面；首先，數(shù)據(jù)庫的配置通常由專業(yè)的 DBA 來負責(zé)；第二，大部分時候，默認的數(shù)據(jù)庫配置在大多數(shù)情況下已經(jīng)是最優(yōu)配置了。
對于開發(fā)人員來說，我們需要把注意力放在后面三點： 數(shù)據(jù)結(jié)構(gòu)的優(yōu)化，也就是表結(jié)構(gòu)的優(yōu)化- 數(shù)據(jù)類型的選擇：選用合適的數(shù)據(jù)結(jié)構(gòu)。什么叫做'合適的數(shù)據(jù)結(jié)構(gòu)'，比如性別字段，M表示男F表示女，那么一個 char(1) 就足夠了，如果存儲人的年齡，那么就沒有必要使用 INT 這么大范圍的字段了；
- 適當(dāng)?shù)牟鸱郑呵f不要試圖把所有的字段放在一張表中，因為這會非常影響性能，通常一張表的字段最好不要超過 30 個；
- 適當(dāng)?shù)娜哂啵喝绻恍┏Ｓ玫淖侄?，可能會用在不同的維度，那么我們可以把這些字段設(shè)計在多張表中，因為這樣可能會減少表關(guān)聯(lián)；
- 字段盡量設(shè)置成 not Null，盡量帶有默認值。
SQL 語句的優(yōu)化優(yōu)化 SQL 語句執(zhí)行速度的方法有很多，比如： - 盡量使用索引，盡量避免全表掃描，提高查詢速度；
- 當(dāng)然你不能無限制地建立索引；維護索引也會影響性能，會降低 DML 操作的速度；
- 注意 SQL 語句的書寫，有一些錯誤的寫法可能會導(dǎo)致索引失效；
- 盡量避免在 where 子句中對字段進行 Null 值判斷（當(dāng)然我們在表設(shè)計中，直接建議不要有 Null）；
- 條件值多的情況下，盡量不要使用 in 和 not in ；
- select 的時候，使用具體的字段代替 * 號
- 避免返回大量數(shù)據(jù)，增加分頁；
減少數(shù)據(jù)庫的訪問- 我們可以通過增加本地緩存或分布式緩存的方式，將熱點數(shù)據(jù)存儲到緩存中，以減少數(shù)據(jù)庫的訪問；
- 終極大招，如果是一個不合理的需求，我們可以拒絕做這個需求，這樣也算是'減少了數(shù)據(jù)庫訪問'。
 說完了 MySQL 本身的優(yōu)化，如果數(shù)據(jù)量進一步增大的話，我們還有什么優(yōu)化的方案呢？ 讀寫分離主庫用于寫，從庫用于讀，將讀寫分散在不同的數(shù)據(jù)庫上，利用多臺機器的資源，來提高數(shù)據(jù)庫的可用性和性能。  分庫分表如果數(shù)據(jù)持續(xù)增多，超過了單臺 MySQL 的支撐上限，那么只能用【分庫分表】這一招了；我們可以采用一定的路由規(guī)則，將數(shù)據(jù)保存到不同的數(shù)據(jù)庫中。 當(dāng)然，如果不是“迫不得已”，我是不太建議分庫分表的，因為這樣極大地增加了系統(tǒng)的復(fù)雜程度，并且會帶來更多的問題需要開發(fā)人員解決。  以上就是常用的 MySQL 優(yōu)化方案，如果是千萬級數(shù)據(jù)量，優(yōu)化 MySQL 本身即可。 會點代碼的大叔 | 原創(chuàng)一個寫代碼的架構(gòu)師，專注程序員的學(xué)習(xí)和成長，關(guān)注并私信我數(shù)字“1”，送你一份程序員大禮包。 |
