檢索性能從快到慢的是（此處是聽人說的）：

• 第一：tinyint，smallint，mediumint，int，bigint
• 第二：char，varchar
• 第三：NULL

解釋（轉(zhuǎn)載）：

整數(shù)類型

1、TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT，分別用8,16,24,32,64存

2、整數(shù)都有UNSIGNED可選屬性 （拿tinyint字段來舉例，unsigned后，字段的取值范圍是0-255，而signed的范圍是-128 - 127。 那么如果我們在明確不需要負(fù)值存在的情況下，通常是不要設(shè)置signed來支持負(fù)數(shù)的。）

3、對于存儲和計(jì)算來說INT(1)和INT(20)是相同的，INT（N）中N只是規(guī)定了一些交互工具來顯示字符的個數(shù)

字符類型

char定長，存儲效率不如varchar，對于短數(shù)據(jù)的查詢優(yōu)于varchar

固定長度的。比如使用uuid作為主鍵，那用char應(yīng)該更合適。

NULL類型

1、索引NULL列要額外的空間

2、進(jìn)行比較和計(jì)算時會對null值進(jìn)行處理，可能導(dǎo)致索引失效

所以盡量不要使用NULL 類型，多使用整數(shù)類型

另外，時間日期數(shù)據(jù)類型

1、不要用字符串存儲日期型數(shù)據(jù)，浪費(fèi)空間

2、DATE能保存從1001到9999年，精度為秒，他把日期和時間封裝到格式為YYYYMMDDHHMMSS的整數(shù)中，使用8字節(jié)

3、TIMESTAMP保存了從1970年以來的秒數(shù)，和Unix時間戳相同，只能保存1970到2038,使用4字節(jié)

4、FROM_UNIXTIME()和UNIX_TIMESTAMP()兩個函數(shù)轉(zhuǎn)換日期和Unix時間戳

5、DATE和TIMESTAMP中存的是時間，但是是哪里的時間呢？？？：前者不管哪里，他就是一個時間表示（與時區(qū)無關(guān)），后者是格林尼治時間。。就是說存儲時DATE就按照給的時間存，TIMESTAMP則是在先根據(jù)所在時區(qū)和給的時間戳算出對應(yīng)的格林尼治時間再存，訪問時DATE就按照他存的時間返回，TIMESTAMP則是根據(jù)存的時間戳（看作格林尼治時間）和所在時區(qū)算出所在時區(qū)的對應(yīng)時間。

6、通常用TIMESTAMP，空間效率高

7、MYSQL沒有提供比秒更小粒度的日期和時間值，如果需要，可以用BIGINT存儲微妙級別的時間戳，或用DOUBLE存儲秒之后的小數(shù)部分。

實(shí)數(shù)類型

1、金融類要用DECIMAL

2、DECIMAL可以保存BIGINT范圍外的整數(shù)

3、FLOAT和DOUBLE使用標(biāo)準(zhǔn)的浮點(diǎn)運(yùn)算進(jìn)行近似計(jì)算

char 和 varchar

1、char是定長，varchar是變長，也就是varchar節(jié)省空間（除非使用ROW——FORMAT=FIXED創(chuàng)建的話）

2、因?yàn)関archar是變長的，所以UPDATE時如果長度變長，就會做額外的工作

3、下列情況使用varchar：字符串列的最大長度比平均長度大很多;列的更新很少（所以碎片不是問題）;使用了像UTF8這樣的字符集（每個字符都使用不同的字節(jié)數(shù)進(jìn)行存儲）

4、CHAR適用情況：很短，或者所有值都接近同一個長度（如MD5）;列經(jīng)常變更

5、末尾空格問題：高版本varchar會保留末尾空格;char和低版本varchar會剔除末尾空格。

6、CHAR(N),VARCHAR(N)中N表示字符數(shù)，而非字節(jié)數(shù)（中文字符在UTF8中占用3字節(jié)）

7、雖然VARCHAR(N)數(shù)據(jù)類型在磁盤中存的就是他所表示的字符串的大小，但是讀取到內(nèi)存中的時候內(nèi)存是會給他分配N*k+1or2（N=255,1;else 2;）（k根據(jù)字符集決定）

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。