字段類型越短越好（可以用int的則不能用bigint，能用tinyint的不能用int） 滿足需求的情況下，字段類型越短，會占用更少的存儲空間，更少的磁盤IO和網絡IO，更少的MySQL計算空間和APP計算空間。常見的字段類型介紹如下：
盡量不要使用default null，所有的字段盡可能都設定為not null并為其定義默認值：
索引不會包括NULL值。影響索引的統計信息，影響優化器的判斷。
復合索引中只要有一列含有NULL值，則該列對于此復合索引將是無效的。
需要多表 join的字段或直接比較的字段，數據類型保持絕對一致。
杜絕隱形轉換，比如int同char進行比較，造成效率低下。
當字段的類型為枚舉型或布爾型時，建議使用tinyint類型。
一般情況下不允許使用TEXT、BLOG，確實需要則拆分。
本質上說,不是MySQL不適合存儲text，而是在太多的情況下我們期望MySQL能夠更加高效的提供小數據查詢/事務處理。
同理，當varchar字段超過一定長度（256）時，建議拆分。
內容明確，不做變更的類型代碼可用枚舉類型
關于存儲IP地址時字段類型的選擇
如果是IPV4地址，存放使用int類型，而不是char(15)。Int只占4個字節，字符型占用16個字節，符合越短越好的原則。另外索引長度降低，檢索效率更高。
如果是IPV6地址，請找DBA商量決定如何存儲。
關于存儲時間字段類型的選擇
對時間范圍沒有要求時，強烈建議采用TIMESTAMP取代DATETIME，因為TIMESTAMP更短（4個字節），而DATETIME占用8個字節
兩者區別如下：
時間范圍： datetime 以'YYYY-MM-DD HH:MM:SS'格式檢索和顯示DATETIME值。支持的范圍為'1000-01-01 00:00:00'到'9999-12-31 23:59:59' TIMESTAMP值不能早于1970或晚于2037 存儲方式： TIMESTAMP1.4個字節儲存 2.值以UTC格式保存 3.時區轉化，存儲時對當前的時區進行轉換，檢索時再轉換回當前的時區。datetime 1.8個字節儲存 2.實際格式儲存 3.與時區無關
字段規范
更新時間 2025-06-17 11:00:22
最近更新時間: 2025-06-17 11:00:22
分享文章
本文為您介紹字段規范。
