在資料庫設計中，尤其在建表的時候，我們需要分別對每個字段確定對應的資料型別。那麼mysql支援的資料型別非常多，選擇正確的、合理的資料型別對後面的查詢速度有直接的影響。不管儲存哪種型別的資料，下面有幾個簡單的設計原則：
更小的資料型別通常更快，因為它們占用更少的磁碟、記憶體和cpu，並且在處理時需要的cpu週期也更少。不過需要確保在設計之前，沒有低估需要儲存的資料值的範圍，因為在後期增加資料型別的範圍是乙個非常痛苦的過程。。。
比如，當我們確定資料值的範圍始終都在0~255之間的整數的話，那麼最好使用tinyint unsigned型別，其儲存大小為1個位元組。
而，tinyint 的範圍是-128~127；
int的範圍是-2^31 (-2,147,483,648) 到 2^31 – 1 (2,147,483,647) 的整型資料（所有數字），儲存大小為4個位元組；
bigint的範圍是 -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) 的整型資料（所有數字）。儲存大小為 8 個位元組；
smallint unsigned的範圍是 –2^15（2^15表示2的15次冪） 到2^15 – 1，即 –32768 到 32767；
smallint 的範圍是 0 到 2^16 – 1，即 0 到 65535，儲存的位元組是2個位元組。
簡單的資料型別的操作通常需要更少的cpu週期。例如：能夠使用整型的資料，就不要定義成int，因為字符集和排序規則使得字元比整型更複雜。能夠使用mysql內建的型別，例如data，就不要使用字串來儲存日期和時間；還有，盡量使用整型來儲存類似於ip位址的一串數字。
這是因為，在有null值的字段上設計索引、索引統計和值比較都更複雜。在可為null值的列被索引時，每個索引記錄需要乙個額外的位元組。如果計畫在某一列上建立索引，那麼就應該盡量避免把這個字段設計成可為null的列。如果定義表結構時沒有指定列為not null, 預設都是允許為null的。
綜上所述，在設計乙個表的時候，第一步先確定每個列的合理的大型別：數字、字串、時間等等。然後，選擇具體的型別，這個時候就要用到上面的三條規則。例如datetime和timestamp列都可以儲存相同型別的資料，即時間和日期，且都可以精確到秒。然而，timestamp只是用了datetime一半的儲存空間，並且會根據時區變化，具有特殊的自動更新能力。不過，timestamp允許的時間範圍要小得多，有時候它的特殊能力會成為障礙。
資料庫如何優化資料型別
應該這樣定義表，它既能儲存所有可能值，同時在磁碟上占用的空間又最小。如果表占用的儲存空間越 小，則 向磁碟寫入或讀取的資料就越少，查詢起來就越快 在處理查詢時，磁碟上的內容會被載入到主記憶體中。所以，表越小，占用的主存空間就越小 被索引占用的空間就越小。如何操作 如果要儲存員工編號，而其可能的最大值...
資料庫中資料型別
1.整型 整型選取原則 第一 要滿足欄位的表示範圍 第二 盡量選擇占用空間小的資料型別 第三 如果不儲存負數，盡量新增unsigned屬性 2.浮點型 整型選取原則 第一 要滿足欄位的表示範圍 第二 盡量選擇占用空間小的資料型別 第三 能選取整型的不選取float型。3.字元型 char和varch...
資料庫中的資料型別
資料庫中的資料型別通常有很多種，也有不同的分類方法。例如最常見的數值型 字元型 日期時間型，也有不太常見的布林型 列舉型 集合型等。要在dbms中實現某種具體資料型別 例如最簡單的integer 的支援，我們可以從以下幾個方面來考慮。1.資料型別的名稱 資料型別名稱可以出現在ddl語句中，也可以出現...