備註型：TINYTEXT ，TEXT ，LONGTEXT 

有些整數型別以及他們最多所能擁有的數字位我們必須有所瞭解：

·TINYINT——這個型別最多可容納三位數。

·SMALLINT——最多可容納五位數。

·MEDIUMINT——最多可容納八位數。

·INT——可以容納十位數。

·BIGINT——最多可容納二十位數。

TEXT可以接受文字輸入，VARCHAR只能接受255個字元，但是TEXT可以用來儲存超量的資料。

當TIMESTAMP資料型別被選定，可以點選“CURRENT_TIMESTAMP”作為預設，MySQL會自動返回每個MySQL資料插入的確切時間。

最近在使用mysql時才真正搞清楚int(11)中11的真正含義，以前只是簡單的以為是用來表示儲存最大為11位長的整數，其實沒有那麼簡單，int型別規定只佔用4個位元組，最長也就是32位，當用有符號數表示時最大值為2147483647，無符號數表示時最大值位4294729693，由此可見，這個數字只是指定最大顯示長度，所以int(10)、int(11)、int(12)應該沒有什麼區別，因為最大數值也就是10位。

MySql支援3個浮點型:float,double,decimal。
float:代表單精度浮點型別。
double:代表雙精度浮點數值。
與整數型別一樣，這些型別帶有附加的引數。一個顯示寬度指示器和一個小數點指示器。
eg： float(5,2)則規定顯示寬度為5的數字，小數點後面有2位數字。對於小數點後面的數字。
超過了允許的數目時，系統會自動將它四捨五入插入。
eg：

1. mysql> create table t7 (abc float(5,2));
   
2. Query OK, 0 rows affected (0.01 sec)
   
3. mysql> insert into t7 values(123.456);
   
4. Query OK, 1 row affected (0.02 sec)
   
5. mysql> select * from t7;
   
6. +--------+
   
7. | abc |
   
8. +--------+
   
9. | 123.46 |
   
10. +--------+
    
11. 1 row in set (0.03 sec)

在正取值範圍的一端，不需要正號，因此MySQL資料型別利用它擴充了取值範圍，使其超過了ANSI 所規範所要求的取值範圍。如DECIMAL(5, 2) 的最大值為9 9 9 9 . 9 9，因為有7 個位元組可用。

一、VARCHAR與CHAR字元型資料的差異

在MySQL資料庫中，用的最多的字元型資料型別就是Varchar和Char.。這兩種資料型別雖然都是用來存放字元型資料，但是無論從結構還是從資料的儲存方式來看，兩者相差很大。而且其具體的實現方式，還依賴與儲存引擎。我這裡就以大家最常用的MYISAM儲存引擎為例，談談這兩種資料型別的差異。在後續建議中，也是針對這種儲存型別而言的。

這裡首先需要明白的一點是，這兩種資料型別，無論採用哪一種儲存引起，系統儲存資料的方式都是不同的。正是因為如此，我們才有必要研究兩者的不同。然後在合適的情況下，採用恰當的方式。瞭解這一點之後，我們再來看後續的內容。

Varchar往往用來儲存可變長度的字串。簡單的說，我們只是給其固定了一個最大值，然後系統會根據實際儲存的資料量來分配合適的儲存空間。為此相比CHAR字元資料而言，其能夠比固定長度型別佔用更少的儲存空間。不過在實際工作中，由於某系特殊的原因，會在這裡設定例外。如管理員可以根據需要指定ROW_FORMAT=FIXED選項。利用這個選項來建立MyISAM表的話，系統將會為每一行使用固定長度的空間。此時會造成儲存空間的損耗。通常情況下，VARCHAR資料型別能夠節約磁碟空間，為此往往認為其能夠提升資料庫的效能。不過這裡需要注意的是，這往往是一把雙刃劍。其在提升效能的同時，往往也會產生一些副作用。如因為其長度是可變的，為此在資料進行更新時可能會導致一些額外的工作。如在更改前，其字元長度是10位（Varchar規定的最長字元數假設是50位），此時系統就只給其分配10個儲存的位置（假設不考慮系統自身的開銷）。更改後，其資料量達到了20位。由於沒有超過最大50位的限制，為此資料庫還是允許其儲存的。只是其原先的儲存位置已經無法滿足其儲存的需求。此時系統就需要進行額外的操作。如根據儲存引擎不同，有的會採用拆分機制，而有的則會採用分頁機制。

CHAR資料型別與VARCHAR資料型別不同，其採用的是固定長度的儲存方式。簡單的說，就是系統總為其分配最大的儲存空間。當資料儲存時，即使其沒有達到最大的長度，系統也會為其分配這麼多的儲存空間。顯然，這種儲存方式會造成磁碟空間的浪費。這裡筆者需要提醒的一點是，當字元位數不足時，系統並不會採用空格來填充。相反，如果在儲存CHAR值的時候，如果其後面有空值，系統還會自動過濾其空格。而在進行資料比較時，系統又會將空格填充到字串的末尾。

顯然，VARCHAR與CHAR兩種字元型資料型別相比，最大的差異就是前者是可變長度，而後者則是固定長度。在儲存時，前者會根據實際儲存的資料來分配最終的儲存空間。而後者則不管實際儲存資料的長度，都是根據CHAR規定的長度來分配儲存空間。這是否意味著CHAR的資料型別劣於VARCHAR呢？其實不然。否則的話，就沒有必要存在CHAR字元型別了。雖然VARCHAR資料型別可以節省儲存空間，提高資料處理的效率。但是其可變長度帶來的一些負面效應，有時候會抵消其帶來的優勢。為此在某些情況下，還是需要使用Char資料型別。

二、專案建議

根據上面的分析，我們知道VARCHAR資料型別是一把雙刃劍，其在帶來效能提升的同時，也可能會存在著一些額外的消耗。我們在評估到底是使用VARCHAR資料型別還是採用CHAR資料型別時，就需要進行均衡。在實際專案中，我們會考量如下情況。

一是根據字元的長度來判斷。如某個欄位，像人的名字，其最長的長度也是有限的。如我們給其分配18個字元長度即可。此時雖然每個人的名字長度有可能不同，但是即使為其分配了固定長度的字元型別，即18個字元長度，最後浪費的空間也不是很大。而如果採用NVARCHAR資料型別時，萬一以後需要改名，而原先的儲存空間不足用來容納新的值，反而會造成一些額外的工作。在這種情況下，進行均衡時，會認為採用CHAR固定長度的資料型別更好。在實際專案中，如果某個欄位的字元長度比較短此時一般是採用固定字元長度。

二是考慮其長度的是否相近。如果某個欄位其長度雖然比較長，但是其長度總是近似的，如一般在90個到100個字元之間，甚至是相同的長度。此時比較適合採用CHAR字元型別。比較典型的應用就是MD5雜湊值。當利用MD5雜湊值來儲存使用者密碼時，就非常使用採用CHAR字元型別。因為其長度是相同的。另外，像用來儲存使用者的身份證號碼等等，一般也建議使用CHAR型別的資料。

另外請大家考慮一個問題，CHAR（1）與VARCHAR（1）兩這個定義，會有什麼區別呢？雖然這兩個都只能夠用來儲存單個的字元，但是VARCHAR要比CHAR多佔用一個儲存位置。這主要是因為使用VARCHAR資料型別時，會多用1個位元組用來儲存長度資訊。這個管理上的開銷CHAR字元型別是沒有的。

三是從碎片角度進行考慮。使用CHAR字元型時，由於儲存空間都是一次性分配的。為此某個欄位的內容，其都是儲存在一起的。單從這個角度來講，其不存在碎片的困擾。而可變長度的字元資料型別，其儲存的長度是可變的。當其更改前後資料長度不一致時，就不可避免的會出現碎片的問題。故使用可變長度的字元型資料時，資料庫管理員要時不時的對碎片進行整理。如執行資料庫匯出匯入作業，來消除碎片。

四是即使使用Varchar資料型別，也不能夠太過於慷慨。這是什麼意思呢？如現在使用者需要儲存一個地址資訊。根據評估，只要使用100個字元就可以了。但是有些資料庫管理員會認為，反正Varchar資料型別是根據實際的需要來分配長度的。還不如給其大一點的呢。為此他們可能會為這個欄位一次性分配200個字元的儲存空間。這VARCHAR（100）與VARCHAR（200）真的相同嗎？結果是否定的。雖然他們用來儲存90個字元的資料，其儲存空間相同。但是對於記憶體的消耗是不同的。對於VARCHAR資料型別來說，硬碟上的儲存空間雖然都是根據實際字元長度來分配儲存空間的，但是對於記憶體來說，則不是。其時使用固定大小的記憶體塊來儲存值。簡單的說，就是使用字元型別中定義的長度，即200個字元空間。顯然，這對於排序或者臨時表（這些內容都需要通過記憶體來實現）作業會產生比較大的不利影響。所以如果某些欄位會涉及到檔案排序或者基於磁碟的臨時表時，分配VARCHAR資料型別時仍然不能夠太過於慷慨。還是要評估實際需要的長度，然後選擇一個最長的欄位來設定字元長度。如果為了考慮冗餘，可以留10%左右的字元長度。千萬不能認為其為根據實際長度來分配儲存空間，而隨意的分配長度，或者說乾脆使用最大的字元長度。