優化資料型別提高效能的主要原理在於以下幾個方面：
1. 通過選用更「小」的資料型別減少儲存空間，使查詢相同資料需要的 io 資源降低；
2. 通過合適的資料型別加速資料的比較；
下面我們還是通過分析一些常用資料型別的資料儲存格式和長度來看看哪些資料型別可以在優化中
利用上吧。
數字日期型別
我們先來看看存放長度基本固定的一些資料型別的儲存長度和取值範圍。
對於數字型別，這裡分別列出了整數型別和小數型別，也就是浮點數型別。實際上，還有一類通過
二進位制格式以字串來存放的數字型別如 decimal(dec)[(m[,d])]，numeric[(m[,d])]，由於其存放長度
主要通過其定義時候的的 m 所決定，m 定義為多大，則實際存放就有多長。m 代表整個位數長度，而 d 則
表示小數點後的位數，預設 m 為 10，d 為 0。一般來說，主要用在固定精度的場合，由於其存放長度較
大，而且考慮到這種資料完全可以變化形式以整數存放，所以筆者個人並不是特別推薦。
對於數字的儲存，一般使用到浮點型資料的場合也不應該太多。主要出於兩個原因，乙個是浮點型
資料本身實際上是乙個並不精確的數字，只是乙個近似值，另乙個原因就是完全可以通過乘以乙個固定
的係數轉換為整型資料來存放。這樣不僅可以解決資料不精確的問題，同時也讓資料的處理更為高效。
時間儲存格式總類並不是太多，我們常用的主要就是 datetime，date 和 timestamp 這三種了。從存
儲空間來看 timestamp 最少，四個位元組，而其他兩種資料型別都是八個位元組，多了一倍。而 timestamp 的
缺點在於他只能儲存從 1970 年之後的時間，而另外兩種時間型別可以存放最早從 1001 年開始的時間。如
果有需要存放早於 1970 年之前的時間的需求，我們必須放棄 timestamp 型別，但是只要我們不需要使用
1970 年之前的時間，最好盡量使用 timestamp 來減少儲存空間的占用。
上面所列出的主要是一些存放固定長度，且我們平時可能常用到的一些型別。通過這個對照**，
我們可以很直觀的看出哪種型別占用的儲存空間大，哪種占用的空間小。這樣，在資料型別選擇的時
候，我們就可以結合各種型別的儲存範圍以及業務中可能存在的資料作出對應，然後選擇儲存空間最先
的型別來使用。
字元儲存型別
我們再來看看存放字元的資料型別。
char[(m)]型別屬於靜態長度型別，存放長度完全以字元數來計算，所以最終的儲存長度是基於字元
集的，如 latin1 則最大儲存長度為 255 位元組，但是如果使用 gbk 則最大儲存長度為 510 位元組。char 型別
的儲存特點是不管我們實際存放多長資料，在資料庫中都會存放 m 個字元，不夠的通過空格補上，m 預設
為 1。雖然char 會通過空格補齊存放的空間，但是在訪問資料的時候，mysql 會忽略最後的所有空格，所
以如果我們的實際資料中如果在最後確實需要空格，則不能使用 char 型別來存放。在 mysql5.0.3 之前的
版本中，如果我們定義 char 的時候 m 值超過 255，mysql 會自動將 char 型別進行轉換為可以存入對應數
據量的 text 型別，如 char(1000) 會自動轉換為 text ， char(10000) 則會轉為 mediumtext 。而從
mysql5.0.3 開始，所有超過 255 的定義 mysql 都會直接拒絕並給出錯誤資訊，不再自動轉換。
varchar[(m)]屬於動態儲存長度型別，僅存占用實際儲存資料的長度。其存放的最大長度與 mysql
版本有關，在 5.0.3 之前的版本 varchar 以字元數控制最儲存的最大長度，最大只能存放 255 個字元，佔
用儲存空間的實際大小與字符集有關。但是從 5.0.3 開始，varchar 的最大儲存限制已經更改為位元組數限
制了，擴充套件到可以存放 65535 bytes 的資料，不同的字符集可能存放的字元數並不一樣。也就是說，在
mysql5.0.3 之前的版本，m 所代表的是字元數，而從 5.0.3 版本開始，m 的代表意思已經是位元組數了。
varchar 的儲存特點是不管我們設定 m 為多大的值，真正占用的儲存空間都只有我們所存入的實際資料的
大小，和 char 不同的是 varchar 會保留我們存入資料最後的空格，也就是說我們存入是什麼樣，mysql
返回給我們的也會是什麼樣。在 varchar 型別欄位的資料中，mysql 會在每個 varchar 資料中使用 1 個或
者 2 個位元組用來存放 varchar 資料的實際長度，當我們的實際資料在 255 位元組之內的時候，會使用 1 位元組
來存放實際長度，而大於 255 位元組的時候，則需要使用 2 位元組來存放。
tinytext，text，mediumtext 和 longtext 這四種型別同屬於一種儲存方式，都是動態儲存長度類
型，不同的僅僅是最大長度的限制。四種型別的定義都是通過最大字元數來限制，但是他們的字元數限
制實際上是可以理解為位元組數限制的，因為當我們使用多位元組字符集的時候，實際能存放的字元書並沒
最大字元數那麼多，而是以單位元組字元來計算的字元數。此外，由於是動態儲存長度型別，所以和
varchar 一樣，每個字段資料之前都需要乙個存放實際長度的空間。tinytext 需要 1 個位元組來存放，text
需要 2 個位元組，mediumtext 和 longtext 則分別需要 3 個和 4 個位元組來存放實際資料長度。實際上，出了
mysql 內嵌的最大長度限 制之外，他們還受到客戶端與伺服器端的網路通訊緩衝區最大值
（max_allowed_packet）的限制。
這四種 text 型別和 char 及 varchar 在實際使用中存在幾個不一樣的地方：
◆ 不能設定預設值；
◆ 只有 text 可以使用 text[(m)]這樣的方式通過 m 設定大小；
◆ 基於這四種型別的索引必須指定字首長度；
其他常用型別
除了上面這些字段型別之外會被我們經常使用到之外，我們還會使用到的資料型別主要有以下這
些。
對於 bit 型別，m 表示每個值的 bits 數目，預設為 1，最大為 64 bits。對於 mysql 來說這是乙個新
的型別，因為從 mysql5.0.3 才開始真正實現（在之前實際上是 tinyint（1）），而且僅僅支援 myisam
儲存引擎，但是從 mysql5.0.5 開始 memory，innodb 和 ndb cluster 儲存引擎也開始「支援」了。在
myisam 中，bit 的儲存空間很小，是真正的實現了通過 bit 來儲存，但是在其他的一些儲存引擎中就不一
樣了，因為他們是轉換為最小的 int 型別儲存的，所以占用的空間也沒有節省，還不如直接使用 int 類的
資料型別存放來得直觀。
對於 set 和 enum 型別，主要內容基本處於較少變化狀態且值比較少的字段。雖然這兩個欄位所占用
的儲存空間都較少，但是由於在使用方面較其他的資料型別要略為複雜一些，所以在實際環境中一般使
用還是較少。
誰都知道，資料量（這裡主要指資料記錄條數）的增加肯定會讓資料庫的檢索查詢效率降低。所以
很多時候人們大都希望通過減少資料庫中關鍵表的記錄條數來獲得資料庫效能的提公升。實際上，除了這
種通過控制資料記錄條數來控制資料總量的辦法之外，我們還可以通過選擇更小的資料型別來讓資料庫
通過更小的空間存放相同的資料量，這對於檢索同樣的資料所帶來的 io 消耗自然會降低，效能也就很自
然得到了提公升。
此外，由於 cpu 對不同資料的處理方式不一樣，就會造成不同型別的資料在各種運算處理如比較，
排序等方面的處理效率存在差異。所以，對於我們需要經常進行比較計算以及排序等消耗 cpu 資源的字
段，應該盡量選擇處理更為迅速的字段型別。如通過整數型別代替浮點數或者字元型別。
mysql資料型別用法 mysql資料型別和用法
歡迎進入linux社群論壇，與200萬技術人員互動交流 進入 mysql支援多種列型別 數值型別 日期 時間型別和字串 字元 型別。本章首先對這些列型別進行了概述，然後更加詳細地描述了各種列的型別，以及列型別儲存需求的總結。概述很簡單。關於具體列型別 歡迎進入linux社群論壇，與200萬技術人員互...
mysql 資料型別 真假 MySQL 資料型別
mysql基礎 資料型別 整型型別 根據所儲存的整數數值取值範圍不同，可分為以下五類 1 tinyint佔1個位元組 2 smallint佔2個位元組 3 mediumint 佔3個位元組 4 int佔4個位元組 5 bigint佔8個位元組 根據每種型別所佔的位元組數可確定其無符號整數和有符號整數...
mysql 郵箱 資料型別 mysql 資料型別
1 整型mysql資料型別含義 有符號 tinyint m 1個位元組 範圍 128 127 smallint m 2個位元組 範圍 32768 32767 mediumint m 3個位元組 範圍 8388608 8388607 int m 4個位元組 範圍 2147483648 21474836...