一、前言

• MySQL 數據庫某張表近千萬的數據，CRUD比較慢，如何優化？
• 說實話，這個數據量級， MySQL 單庫單表支撐起來完全沒有問題的，所以首先還是考慮數據庫本身的優化。

• 從上圖可以看到，數據庫優化通常可以通過以上幾點來實現：
  • 硬件升級：也就是花更多的錢，升級我們數據庫硬件配置，包括 CPU、內存、磁盤、網絡等等，但是這個方案成本高，而且不一定能起到非常好的效果。
  • 數據庫配置：修改數據庫的配置，有可能讓我們的 CRUD 操作變得更快，不過我也不建議大家把經歷放在這一點上面；首先，數據庫的配置通常由專業的 DBA 來負責；第二，大部分時候，默認的數據庫配置在大多數情況下已經是最優配置了。

二、優化

① 數據結構的優化，也就是表結構的優化

• 數據類型的選擇：選用合適的數據結構。什么叫做"合適的數據結構"，比如性別字段，M表示男F表示女，那么一個 char(1) 就足夠了，如果存儲人的年齡，那么就沒有必要使用 INT 這么大范圍的字段了；
• 適當的拆分：千萬不要試圖把所有的字段放在一張表中，因為這會非常影響性能，通常一張表的字段最好不要超過 30 個；
• 適當的冗余：如果一些常用的字段，可能會用在不同的維度，那么我們可以把這些字段設計在多張表中，因為這樣可能會減少表關聯；
• 字段盡量設置成 not Null，盡量帶有默認值。

② SQL 語句的優化

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

③ 減少數據庫的訪問

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

• 說完了 MySQL 本身的優化，如果數據量進一步增大的話，我們還有什么優化的方案呢？

④ 讀寫分離

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

⑤ 分庫分表

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。