| 整數類型 | 空間大小（bit） |
|---|---|
| TINYINT | 8 |
| SMALLINT | 16 |
| MEDIUMINT | 24 |
| INT | 32 |
| BIGINT | 64 |
整數類型所能存儲的范圍和空間大小有關：-2^(N-1)至2^(N-1)-1，其中N為空間大小的位數。
整數類型具有UNSIGNED的可選屬性，當聲明時，表示不允許負數，則存儲范圍變?yōu)椋?至2^(N)-1，擴大了一倍。
在MySQL中，還可以為整數類型指定寬度，例如INT(1)，但這樣的意義并不大，并不會限制值的合法范圍，仍能存儲-2^31至2^31-1的值，所影響的是與MySQL的交互工具顯示字符的個數。
1.2 實數類型
實數類型的對比如下：
| 實數類型 | 空間大?。˙yte） | 取值范圍 | 計算精度 |
|---|---|---|---|
| FLOAT | 4 | 負數：-3.4E+38～-1.17E-38；非負數：0、1.17E-38~3.4E+38 | 近似計算 |
| DOUBLE | 8 | 負數：-1.79E+308～-2.22E-308；非負數：0、2.22E-308~1.79E+308 | 近似計算 |
| DECIMAL | 與精度有關 | 同DOUBLE | 精確計算 |
從上面可以看出，FLOAT和DOUBLE都有固定的空間大小，但同時由于是使用標準的浮點運算，所以只能近似計算。而DECIMAL則可以實現精確計算，與此同時占用的空間會相較更大，所耗費的計算開銷也更多。
DECIMAL所占空間大小與指定的精度有關，例如DECIMAL(M,D)：
MySQL在存儲DECIMAL類型時會作為二進制字符串存儲，每4個字節(jié)存9個數字，當不足9位時，數字的占用空間如下：
| 數字個數 | 占用空間（Byte） |
|---|---|
| 1、2 | 1 |
| 3、4 | 2 |
| 5、6 | 3 |
| 7、8 | 4 |
小數點前后將分別存儲，同時小數點也要占1個字節(jié)。下面舉兩個計算的例子：
可以看出DECIMAL的空間占用還是很大的，因此只有當需要對小數進行精確計算時，才需要使用DECIMAL。除此之外，我們還可以使用BIGINT代替DECIMAL，例如需要保證小數點后5位的計算，可以將值乘上10的5次方后作為BIGINT存儲，這樣能同時避免浮點存儲計算不精確和DECIMAL精確計算代價高的問題。
1.3 字符串類型
最常用的字符串類型當屬VARCHAR和CHAR。 VARCHAR 作為 可變長字符串 ，會使用1或2個額外字節(jié)記錄字符串的長度，當最大長度未超過255時，只需1個字節(jié)記錄長度，超過255，則需2個字節(jié)。VARCHAR的 適用場景 ：
CHAR則為 定長字符串 ，根據定義的字符串長度分配足夠的空間， 適用場景 ：
除了VARCHAR和CHAR，針對存儲大字符串，可以使用BLOB和TEXT類型。BLOB和TEXT的區(qū)別在于， BLOB 是以 二進制 方式存儲，而 TEXT 是以 字符 方式存儲。這也導致，BLOB類型的數據沒有字符集的概念，無法按字符排序，而TEXT類型則有字符集的概念，可以按字符排序。兩者的使用場景，也由存儲格式決定了，當存儲二進制數據時，例如圖片，應使用BLOB，而存儲文本時，例如文章，則應使用TEXT類型。
1.4 日期和時間類型
MySQL中所能存儲的最小時間粒度為秒，常用的日期類型有DATETIME和TIMESTAMP。
| 類型 | 存儲內容 | 空間大小（Byte） | 時區(qū)概念 |
|---|---|---|---|
| DATETIME | 格式為YYYYMMDDHHMMSS的整數 | 8 | 無 |
| TIMESTAMP | 從1970年1月1日零點以來的秒數 | 4 | 有 |
TIMESTAMP顯示的值將依賴于時區(qū)，意味在不同時區(qū)查詢到的值將不一樣。除了以上列出的不同，TIMESTAMP還具有一個特殊屬性，在插入和更新時，如果沒有指定第一個TIMESTAMP列的值，將會設置這個列的值為當前時間。
我們在開發(fā)過程中，應盡量使用TIMESTAMP，主要是因為其空間大小僅需DATETIME的一半，空間效率更高。
如果我們想存儲的日期和時間精確到秒之后，怎么辦？由于MySQL并未提供，所以我們可以使用BIGINT存儲微妙級別的時間戳，或者使用DOUBLE存儲秒之后的小數部分。
1.5 選擇標識符
通常來說整數是標識符的最好選擇，主要是因為其簡單，計算快，且可使用AUTO_INCREMENT。
2. 范式和反范式
簡單來說，范式就是一張數據表的表結構所符合的某種設計標準的級別。第一范式，屬性不可分割，現在的RDBMS系統(tǒng)建成的表都是符合第一范式的。而第二范式，則是消除非主屬性對碼（可以理解為主鍵）的部分依賴。第三范式消除非主屬性對碼的傳遞依賴。
嚴格 范式化 的數據庫中，每個事實數據會出現且只出現一次， 不會出現數據冗余 ，這樣所能帶能帶來的好處有：
但也由于數據分散存在各張表中，查詢時需要對表進行關聯。而 反范式 的優(yōu)點則是 不用進行關聯 ，將數據冗余存儲。
在實際應用中，不會出現完全的范式化或完全的反范式化，時常需要 混用范式和反范式 ，使用部分范式化的schema，往往是最好的選擇。關于數據庫設計，在網上看到這樣一段話，大家可以感受下。
數據庫設計應該分為三個境界：
第一境界：剛入門數據庫設計，范式的重要性還未深刻理解。這時候出現的反范式設計，一般會出問題。
第二境界：隨著遇到問題解決問題，漸漸了解到范式的真正好處，從而能快速設計出低冗余、高效率的數據庫。
第三境界：再經過N年的鍛煉，是一定會發(fā)覺范式的局限性的。此時再去打破范式，設計更合理的反范式部分。
范式就像武俠里面的招數，初學者妄想不按招數來，只能死的很難堪。畢竟招數都是高手總結歸納的精華。而隨著武功提高，招數熟練之后，必然是發(fā)現招數的局限性，要么忘掉招數，要么自創(chuàng)招數。
只要努力，加上多熬幾年，總能達到第二個境界，總會覺得范式是經典。此時能不過分依賴范式，快速突破范式局限性的人，自然是高手。
3. 緩存表和匯總表
除了上述說到的反范式，在表中存儲冗余數據，我們還可以創(chuàng)建一張完全獨立的匯總表或緩存表，來滿足檢索的需要。
緩存表，指的是存儲可以從schema其他表中獲取數據的表，也就是邏輯上冗余的數據。而 匯總表 ，則指的是存儲使用GROUP BY等語句聚合數據，計算出的不冗余的數據。
緩存表，可用于 優(yōu)化搜索和檢索查詢語句 ，這里可以使用的技巧有對緩存表使用不同的存儲引擎，例如主表使用InnoDB，而緩存表則可使用MyISAM，獲得更小的索引占用空間。甚至可以將緩存表放到專門的搜索系統(tǒng)中，例如Lucene。
匯總表，則是為了 避免實時計算統(tǒng)計值所帶來的高昂代價 ，代價來自兩方面，一是需要掃描表中的大部分數據，二是建立特定的索引，會對UPDATE操作有影響。例如，查詢微信過去24小時的朋友圈數量，則可固定每1小時掃描全表，統(tǒng)計后寫一條記錄到匯總表，當查詢時，只需查詢匯總表上最新的24條記錄，而不必每次查詢時都去掃描全表進行統(tǒng)計。
在使用緩存表和匯總表時，必須決定是 實時維護數據 還是 定期重建 ，這取決于我們的需求。定期重建相比實時維護，能節(jié)省更多的資源，表的碎片更少。而在重建時，我們仍需保證數據在操作時可用，需要通過“ 影子表 ”來實現。在真實表后創(chuàng)建一張影子表，當填充好數據后，通過原子的重命名操作來切換影子表和原表。
4. 加快ALTER TABLE操作的速度
當MySQL在執(zhí)行ALTER TABLE操作時，往往是新建一張表，然后把數據從舊表查出并插入到新表中，再刪除舊表，如果表很大，這樣需要花費很長時間，且會導致MySQL的服務中斷。為了避免服務中斷，通常可以使用 兩種技巧 ：
在一臺不提供服務的機器上執(zhí)行ALTER TABLE操作，然后再與提供服務的主庫進行切換；
“影子拷貝”，建立一張與原表無關的新表，在數據遷移完成后，通過重命名操作進行切換。
但也 不是所有的ALTER TABLE操作會引起表重建 ，例如在修改字段的默認值時，使用MODIFY COLUMN會進行表重建，而使用ALTER COLUMN則不會進行表重建，操作速度很快。這是因為ALTER COLUMN在修改默認值時，會直接修改了存在表的.frm文件（存儲字段的默認值），而并未重建表。
參考
《高性能MySQL》
MySQL DECIMAL 數據類型
以上就是詳解MySQL中的數據類型和schema優(yōu)化的詳細內容，更多關于MySQL 數據類型和schema優(yōu)化的資料請關注腳本之家其它相關文章！
標簽：天津 公主嶺 沈陽 呼和浩特 合肥 阿里 牡丹江 惠州
巨人網絡通訊聲明：本文標題《詳解MySQL中的數據類型和schema優(yōu)化》，本文關鍵詞 詳解,MySQL,中的,數據,類型,；如發(fā)現本文內容存在版權問題，煩請?zhí)峁┫嚓P信息告之我們，我們將及時溝通與處理。本站內容系統(tǒng)采集于網絡，涉及言論、版權與本站無關。
