一、前言

• 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 來負(fù)責(zé)；第二，大部分時候，默認(rèn)的數(shù)據(jù)庫配置在大多數(shù)情況下已經(jīng)是最優(yōu)配置了。

二、優(yōu)化

① 數(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ù)牟鸱?#xff1a;千萬不要試圖把所有的字段放在一張表中，因為這會非常影響性能，通常一張表的字段最好不要超過 30 個；
• 適當(dāng)?shù)娜哂?#xff1a;如果一些常用的字段，可能會用在不同的維度，那么我們可以把這些字段設(shè)計在多張表中，因為這樣可能會減少表關(guān)聯(lián)；
• 字段盡量設(shè)置成 not Null，盡量帶有默認(rèn)值。

② SQL 語句的優(yōu)化

• 選取最適用的字段屬性：表中字段的寬度設(shè)得盡可能小：char 的上限為 255 字節(jié)（固定占用空間），varchar 的上限 65535 字節(jié)（實際占用空間），text 的上限為 65535。盡量把字段設(shè)置為 NOT NULL，執(zhí)行查詢的時候，數(shù)據(jù)庫不用去比較 NULL 值。
• 盡量使用索引，盡量避免全表掃描，提高查詢速度；
  • 查詢語句當(dāng)中包含有 MAX (), MIN () 和 ORDERBY 這些命令的時候，性能提高更為明顯。
  • 索引應(yīng)建立在那些將用于 JOIN, WHERE 判斷和 ORDER BY 排序的字段上。
  • 盡量不要對數(shù)據(jù)庫中某個含有大量重復(fù)的值的字段建立索引。
  • 對于一個 ENUM 類型的字段來說，出現(xiàn)大量重復(fù)值是很有可能的情況，例如 customerinfo 中的 “province”… 字段，在這樣的字段上建立索引將不會有什么幫助；相反，還有可能降低數(shù)據(jù)庫的性能。
• 當(dāng)然你不能無限制地建立索引；維護(hù)索引也會影響性能，會降低 DML 操作的速度；
• 注意 SQL 語句的書寫，有一些錯誤的寫法可能會導(dǎo)致索引失效；
  • SELECT FROM order WHERE YEAR(OrderDate)<2001;
  • SELECT FROM order WHERE OrderDate<“2001-01-01”;
  • SELECT FROM inventory WHERE Amount/7<24;
  • SELECT FROM inventory WHERE Amount<24*7;
• 盡量避免在 where 子句中對字段進(jìn)行 Null 值判斷（當(dāng)然我們在表設(shè)計中，直接建議不要有 Null）；
• 條件值多的情況下，盡量不要使用 in 和 not in ；
• select 的時候，使用具體的字段代替 * 號；
• 避免返回大量數(shù)據(jù)，增加分頁。

③ 減少數(shù)據(jù)庫的訪問

• 我們可以通過增加本地緩存或分布式緩存的方式，將熱點數(shù)據(jù)存儲到緩存中，以減少數(shù)據(jù)庫的訪問；
• 終極大招，如果是一個不合理的需求，我們可以拒絕做這個需求，這樣也算是"減少了數(shù)據(jù)庫訪問"。

• 說完了 MySQL 本身的優(yōu)化，如果數(shù)據(jù)量進(jìn)一步增大的話，我們還有什么優(yōu)化的方案呢？

④ 讀寫分離

• 主庫用于寫，從庫用于讀，將讀寫分散在不同的數(shù)據(jù)庫上，利用多臺機(jī)器的資源，來提高數(shù)據(jù)庫的可用性和性能。

⑤ 分庫分表

• 如果數(shù)據(jù)持續(xù)增多，超過了單臺 MySQL 的支撐上限，那么只能用【分庫分表】這一招了；我們可以采用一定的路由規(guī)則，將數(shù)據(jù)保存到不同的數(shù)據(jù)庫中。
• 當(dāng)然，如果不是“迫不得已”，我是不太建議分庫分表的，因為這樣極大地增加了系統(tǒng)的復(fù)雜程度，并且會帶來更多的問題需要開發(fā)人員解決。

總結(jié)

以上是生活随笔為你收集整理的MySQL之某个表中有近千万数据且CRUD访问缓慢的优化处理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。