MySQL作為目前最流行的關系型數據庫管理系統之一，其本身或者在工作的過程中還是存在一些缺陷的，這就需要我們進行優化工作。而在優化工作中，我們很容易忽視一些小的細節，比如說數據類型。本文我們就來講一講MySql數據類型優化。

我們都知道選擇數據類型只要遵循小而簡單的原則就好，越小的數據類型通常會更快，占用更少的磁盤、內存，處理時需要的CPU周期也更少。越簡單的數據類型在計算時需要更少的CPU周期，比如，整型就比字符操作代價低，因而會使用整型來存儲ip地址，使用DATETIME來存儲時間，而不是使用字符串。我們可以根據以上的規則來制定MySql數據類型優化的方案。

1.通常來說把可為NULL的列改為NOT NULL不會對性能提升有多少幫助，只是如果計劃在列上創建索引，就應該將該列設置為NOT NULL。

2.對整數類型指定寬度，比如INT(11)，沒有任何卵用。INT使用32位（4個字節）存儲空間，那么它的表示范圍已經確定，所以INT(1)和INT(20)對于存儲和計算是相同的。

3.UNSIGNED表示不允許負值，大致可以使正數的上限提高一倍。比如TINYINT存儲范圍是-128 ~ 127，而UNSIGNED TINYINT存儲的范圍卻是0 - 255。

4.通常來講，沒有太大的必要使用DECIMAL數據類型。即使是在需要存儲財務數據時，仍然可以使用BIGINT。比如需要精確到萬分之一，那么可以將數據乘以一百萬然后使用BIGINT存儲。這樣可以避免浮點數計算不準確和DECIMAL精確計算代價高的問題。

5.TIMESTAMP使用4個字節存儲空間，DATETIME使用8個字節存儲空間。因而，TIMESTAMP只能表示1970 - 2038年，比DATETIME表示的范圍小得多，而且TIMESTAMP的值因時區不同而不同。

6.大多數情況下沒有使用枚舉類型的必要，其中一個缺點是枚舉的字符串列表是固定的，添加和刪除字符串（枚舉選項）必須使用ALTER TABLE（如果只只是在列表末尾追加元素，不需要重建表）。

7.schema的列不要太多。原因是存儲引擎的API工作時需要在服務器層和存儲引擎層之間通過行緩沖格式拷貝數據，然后在服務器層將緩沖內容解碼成各個列，這個轉換過程的代價是非常高的。如果列太多而實際使用的列又很少的話，有可能會導致CPU占用過高。

8.大表ALTER TABLE非常耗時，MySQL執行大部分修改表結果操作的方法是用新的結構創建一個張空表，從舊表中查出所有的數據插入新表，然后再刪除舊表。尤其當內存不足而表又很大，而且還有很大索引的情況下，耗時更久。

以上就是為大家總結的MySql數據類型優化的一些方案，希望能夠為我們在使用MySQL數據庫時起到小小的幫助。盡管，MySQL優化對MySQL的工作效率影響不是很大，但對于程序的運行效率和數據的查詢效率都有很大的提高，因此也是值得我們付諸行動去進行MySQL數據庫優化工作的。在本站的MySQL教程里還有更多的MySQL數據庫優化的一些細節，想學習的小伙伴抓緊時間觀看教程吧！