MySQL優化之表構造優化的5年夜建議（數據類型選擇講的很好）。本站提示廣大學習愛好者：（MySQL優化之表構造優化的5年夜建議（數據類型選擇講的很好））文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL優化之表構造優化的5年夜建議（數據類型選擇講的很好）正文
卻不知，在N年前被奉為“聖經”的數據庫設計3范式早就曾經不完整實用了。這裡我整頓了一些比擬罕見的數據庫表構造設計方面的優化技能，願望對年夜家有效。
因為MySQL數據庫是基於行(Row)存儲的數據庫，而數據庫操作 IO 的時刻是以 page(block)的方法，也就是說，假如我們每筆記錄所占用的空間量減小，就會使每一個page中可寄存的數據行數增年夜，那末每次 IO 可拜訪的行數也就增多了。反過去說，處置雷同行數的數據，須要拜訪的 page 就會削減，也就是 IO 操作次數下降，直接晉升機能。另外，因為我們的內存是無限的，增長每一個page中寄存的數據行數，就等於增長每一個內存塊的緩存數據量，同時還會晉升內存換中數據射中的概率，也就是緩存射中率。
1、數據類型選擇
數據庫操作中最為耗時的操作就是 IO 處置，年夜部門數據庫操作 90% 以上的時光都花在了 IO 讀寫下面。所以盡量削減 IO 讀寫量，可以在很年夜水平上進步數據庫操作的機能。
我們沒法轉變數據庫中須要存儲的數據，然則我們可以在這些數據的存儲方法方面花一些心思。上面的這些關於字段類型的優化建議重要實用於記載條數較多，數據量較年夜的場景，由於精致化的數據類型設置能夠帶來保護本錢的進步，過度優化也能夠會帶來其他的成績：
1.數字類型：非萬不得已不要應用DOUBLE，不只僅只是存儲長度的成績，同時還會存在准確性的成績。異樣，固定精度的小數，也不建議應用DECIMAL，建議乘以固定倍數轉換成整數存儲，可以年夜年夜節儉存儲空間，且不會帶來任何附加保護本錢。關於整數的存儲，在數據量較年夜的情形下，建議辨別開 TINYINT / INT / BIGINT 的選擇，由於三者所占用的存儲空間也有很年夜的差異，能肯定不會應用正數的字段，建議添加unsigned界說。固然，假如數據量較小的數據庫，也能夠不消嚴厲辨別三個整數類型。
2.字符類型：非萬不得已不要應用 TEXT 數據類型，其處置方法決議了他的機能要低於char或許是varchar類型的處置。定長字段，建議應用 CHAR 類型，不定長字段盡可能應用 VARCHAR，且僅僅設定恰當的最年夜長度，而不長短常隨便的給一個很年夜的最年夜長度限制，由於分歧的長度規模，MySQL也會有紛歧樣的存儲處置。
3.時光類型：盡可能應用TIMESTAMP類型，由於其存儲空間只須要 DATETIME 類型的一半。關於只須要准確到某一天的數據類型，建議應用DATE類型，由於他的存儲空間只須要3個字節，比TIMESTAMP還少。不建議經由過程INT類型類存儲一個unix timestamp 的值，由於這太不直不雅，會給保護帶來不用要的費事，同時還不會帶來任何利益。
4.ENUM & SET：關於狀況字段，可以測驗考試應用 ENUM 來寄存，由於可以極年夜的下降存儲空間，並且即便須要增長新的類型，只需增長於末尾，修正構造也不須要重建表數據。假如是寄存可事後界說的屬性數據呢？可以測驗考試應用SET類型，即便存在多種屬性，異樣可以熟能生巧，同時還可以節儉不小的存儲空間。
5.LOB類型：激烈否決在數據庫中寄存 LOB 類型數據，固然數據庫供給了如許的功效，但這不是他所善於的，我們更應當讓適合的對象做他善於的工作，能力將其施展到極致。在數據庫中存儲 LOB 數據就像讓一個多年前在黉捨學過一點Java的營銷專業人員來寫 Java 代碼一樣。
2、字符編碼
字符集直接決議了數據在MySQL中的存儲編碼方法，因為異樣的內容應用分歧字符集表現所占用的空間年夜小會有較年夜的差別，所以經由過程應用適合的字符集，可以贊助我們盡量削減數據量，進而削減IO操作次數。
1.純拉丁字符能表現的內容，沒需要選擇 latin1 以外的其他字符編碼，由於這會節儉年夜量的存儲空間
2.假如我們可以肯定不須要寄存多種說話，就沒需要非得應用UTF8或許其他UNICODE字符類型，這回形成年夜量的存儲空間糟蹋
3.MySQL的數據類型可以准確到字段，所以當我們須要年夜型數據庫中寄存多字節數據的時刻，可以經由過程對分歧表分歧字段應用分歧的數據類型來較年夜水平減小數據存儲量，進而下降 IO 操作次數並進步緩存射中率
3、恰當拆分
有些時刻，我們能夠會願望將一個完全的對象對應於一張數據庫表，這關於運用法式開辟來講是很有好的，然則有些時刻能夠會在機能上帶來較年夜的成績。
當我們的表中存在相似於 TEXT 或許是很年夜的 VARCHAR類型的年夜字段的時刻，假如我們年夜部門拜訪這張表的時刻都不須要這個字段，我們就該義無返顧的將其拆分到別的的自力表中，以削減經常使用數據所占用的存儲空間。如許做的一個顯著利益就是每一個數據塊中可以存儲的數據條數可以年夜年夜增長，既削減物理 IO 次數，也能年夜年夜進步內存中的緩存射中率。
下面幾點的優化都是為了削減每筆記錄的存儲空間年夜小，讓每一個數據庫中可以或許存儲更多的記載條數，以到達削減 IO 操作次數，進步緩存射中率。上面這個優化建議能夠許多開辟人員都邑認為不太懂得，由於這是典范的反范式設計，並且也和下面的幾點優化建議的目的相違反。
4、過度冗余
為何我們要冗余？這不是增長了每條數據的年夜小，削減了每一個數據塊可寄存記載條數嗎？
確切，如許做是會增年夜每筆記錄的年夜小，下降每筆記錄中可寄存數據的條數，然則在有些場景下我們依然照樣不能不如許做：
被頻仍援用且只能經由過程 Join 2張（或許更多）年夜表的方法能力獲得的自力小字段
如許的場景因為每次Join僅僅只是為了獲得某個小字段的值，Join到的記載又年夜，會形成年夜量不用要的 IO，完整可以經由過程空間換取時光的方法來優化。不外，冗余的同時須要確保數據的分歧性不會遭到損壞，確保更新的同時冗余字段也被更新
5、盡可能應用 NOT NULL
NULL 類型比擬特別，SQL 難優化。固然 MySQL NULL類型和 Oracle 的NULL 有差別，會進入索引中，但假如是一個組合索引，那末這個NULL 類型的字段會極年夜影響全部索引的效力。另外，NULL 在索引中的處置也是特別的，也會占用額定的寄存空間。
許多人認為 NULL 會節儉一些空間，所以盡可能讓NULL來到達節儉IO的目標，然則年夜部門時刻這會拔苗助長，固然空間上能夠確切有必定節儉，卻是帶來了許多其他的優化成績，不只未將IO量省上去，反而加年夜了SQL的IO量。所以盡可能確保 DEFAULT 值不是 NULL，也是一個很好的表構造設計優化習氣。
