MySQL之某個表中有近千萬數據且CRUD訪問緩慢的優化處理

Mysql 數據庫某張表近千萬的數據，CRUD比較慢，如何優化？

說實話，這個數據量級， Mysql 單庫單表支撐起來完全沒有問題的，所以首先還是考慮數據庫本身的優化。

從上圖可以看到，數據庫優化通常可以通過以上幾點來實現：

硬件升級：也就是花更多的錢，升級我們數據庫硬件配置，包括 CPU、內存、磁盤、網絡等等，但是這個方案成本高，而且不一定能起到非常好的效果。

數據庫配置：修改數據庫的配置，有可能讓我們的 CRUD 操作變得更快，不過我也不建議大家把經歷放在這一點上面；首先，數據庫的配置通常由專業的 DBA 來負責；第二，大部分時候，默認的數據庫配置在大多數情況下已經是最優配置了。

數據類型的選擇：選用合適的數據結構。什么叫做"合適的數據結構"，比如性別字段，M表示男F表示女，那么一個 char(1) 就足夠了，如果存儲人的年齡，那么就沒有必要使用 INT 這么大范圍的字段了；

適當的拆分：千萬不要試圖把所有的字段放在一張表中，因為這會非常影響性能，通常一張表的字段最好不要超過 30 個；

適當的冗余：如果一些常用的字段，可能會用在不同的維度，那么我們可以把這些字段設計在多張表中，因為這樣可能會減少表關聯；

字段盡量設置成 not Null，盡量帶有默認值。

選取最適用的字段屬性：表中字段的寬度設得盡可能小：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 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。