在設計資料庫結構的時候，要分別對錶和欄位進行相應的優化設計。當然還有其他的方面，其他的方面的優化知識可以去看看我的博文中Mysql分類的文章。

表方面

• 核心欄位且常用欄位，應該建立建立成定長，比如說int ,char等定長，並且這些定長的欄位放在一張表中，這種表又稱為Fixed Format，固定格式。
• 常用欄位和不常用欄位要分離。需要結合網站具體的業務來分析,分析欄位的查詢場景,查詢頻度低的欄位,單拆出來。
• 在1對多的情況下，需要在關聯統計的表上新增冗餘欄位。

欄位方面

• 欄位型別優先順序

整型 > date,time > enum,char>varchar > blob,text
 

• 列的特點分析

（1）整型
定長，沒有國家/地區之分，沒有字符集的差異。比如 tinyint 1,2,3,4,5 <--> char(1) a,b,c,d,e。從空間上,都是佔1個位元組,但是 order by 排序, 前者快？
原因: 後者需要考慮字符集與校對集(就是排序規則)

（2）time
定長，運算快，節省空間。 考慮時區，寫sql時不方便 where > ‘2005-10-12’;

（3）enum 列舉型
能起到約束值的目的,內部用整型來儲存,但與char聯查時,內部要經歷串與值的轉化。性別等欄位最好用tinyint，不要用enum型。

（4）字元型
char，定長，需要考慮字符集和(排序)校對集
varchar, 不定長，要考慮字符集的轉換與排序時的校對集,速度慢
text/Blob，無法使用記憶體臨時表(排序等操作只能在磁碟上進行)

• 注意點

（1）性別：
以utf8為例，char(1) , 3個字長位元組
enum(‘男’,’女’); 內部轉成數字來存,多了一個轉換過程
tinyint() , // 0 1 2 // 定長1個位元組.

（2）夠用就行,不要慷慨 (如smallint,varchar(N))
原因: 大的欄位浪費記憶體,影響速度,
以年齡為例 tinyint unsigned not null ,可以儲存255歲,足夠。用int浪費了3個位元組
如果varchar(10) ,varchar(300)儲存的內容相同, 但在表聯查時,varchar(300)要花更多記憶體

（3）儘量避免用NULL()
原因: NULL不利於索引,要用特殊的位元組來標註.
在磁碟上佔據的空間其實更大.(mysql5.7已對null做的改進,但查詢仍是不便)