關於mysql的字段型別的選取，以前一直沒有時間總結，導致有時自己操作時也會很模糊，今天有時間整理了一下，好了不扯了現在開始
1數值型
型別 建議 位元組 取值
tinyint 非常小的整數（百） 1 -128-127 | 0-255
smallint 較小的整數（萬） 2 -32768-32767 | 0-65535
mediumint 中等大小的整數（千萬) 3 -8388608-8388607 | 0-16777215
int 標準整數（億） 4 -2147483648-2147483647 | 0-4294967295
bigint 大整數（特別大） 8 -9223372036854775808-9223372036854775807 | 0-18446744073709551615
float 單精度浮點數 4 +-3.402823466e+38到+-1.175494351e-38
double 雙精度浮點數 8 +-2.2250738585072014e-308到+-1.7976931348623157e+308
decimal與float和double的區別是：decimal型別的值是以字串的形式被儲存起來的，它的小數字數是固定的。它的優點是，不會象float和double類
型資料列那樣進行四捨五入而產生誤差，所以很適合用於財務計算；而它的缺點是：由於它的儲存格式不同，cpu不能對它進行直接運算，從而影響運算效率。
decimal(m，d)總共要占用m+2個位元組。
2字串
型別char[(m)] m位元組 m位元組
varchar[(m)] m位元組 l+1位元組
tinyblob，tinytext 2^8-1位元組 l+1位元組
blob，text 2^16-1位元組 l+2
mediumblob，mediumtext 2^24-1位元組 l+3
longblob，longtext 2^32-1位元組 l+4
enum('value1',...) 65535個成員 1或2位元組
set('value1',...) 64個成員 1,2,3或8位元組
char和varchar區別乙個是固定長度乙個可變，而後者適用於長度不固定，如果固定則不適宜，因為它會有一位來儲存其長度，這樣就浪費了
blob是二進位制字串，text是非二進位制字串，其中的l+n表示資料列可變長度，mysql處理長度可變的資料時要把資料的長度儲存起來
enum和set型別的資料列定義裡有乙個列表，列表裡的元素就是該資料列的合法取值
3日期時間
date 3(位元組） 「1000-01-01」-「9999-12-31」
time 3 「-838:59:59」-「838:59:59」
datetime 8 」1000-01-01 00:00:00—「9999-12-31 23:59:59「
timestamp 4 1970/01/01到2037 格式：yyyymmddhhmmss
year 1 1901-2155
＊＊這裡補充一下：（m）顯示寬度與儲存大小或型別包含的值的範圍無關，但如果乙個整型列中儲存乙個超過顯示寬度的更大值時，那麼在mysql進行某些復合的聯結查詢生成臨時表時，有可能就會出問題，因為這種情況下mysql通常會信任地認為所有值均適合原始的列寬度，問題就出在這裡了。
不夠全面，回頭再補
MySQL之索引 索引欄位的選取
日常在建資料表的時候，通常會在where，group by，order by等常用的字段上建立索引，當有多個字段時候，有一項原則就是該字段的去重後的值個數越多，索引建立的必要性越強。這裡建立一張資料表，有staff id和leader id兩個字段，通過explain分析可以驗證哪個欄位更適合做索引...
mysql 優化系列之欄位型別選取
mysql 優化是乙個很有意思的話題，可以從很多方面來說，大到伺服器集群，應用體系架構等，小到字段型別選擇，儲存引擎的選擇等，隨著mysql的發展，到目前 最新版本是8.0,筆者5.7 innodb 已是預設的儲存引擎 mysql 5.5 已將innodb作為預設儲存引擎 所以盡量選擇使用innod...
mysql優化系列之欄位型別選取
mysql 優化是乙個很有意思的話題，可以從很多方面來說，大到伺服器集群，應用體系架構等，小到字段型別選擇，儲存引擎的選擇等，隨著mysql的發展，到目前 最新版本是8.0,筆者5.7 innodb 已是預設的儲存引擎 mysql 5.5 已將innodb作為預設儲存引擎 所以盡量選擇使用innod...