1. 選擇優化的資料型別

1. 最小資料型別
2. 簡單資料型別
3. 儘量避免NULL

選擇資料型別時：

1. 需要確定合適的大型別：數字、字串、時間。
2. 選擇具體的型別。考慮長度、範圍，允許的精度，需要的物理空間。

例如

選擇時間時，DATETIME 和 TIMESAMP 都可以儲存相同型別的資料：日期，時間，精確到秒。

然而TIMESAMP 只使用 DATETIME 一半的儲存空間，並且會根據時區變化，具有特殊的自動更新能力。

另一方面，TIMESAMP 允許的時間範圍要小得多，有時候它的特殊能力會成為障礙。

1.1 整數型別

有兩種型別的數字：

1. 整數
2. 實數

如果是儲存整數：

1. TINYINT (8)
2. SMALLINT (16)
3. MEDIUMINT (24)
4. INT (32)
5. BIGINT (64)

整數型別有可選的 UNSIGNED 屬性，表示不允許負值，這大致可以使正數的上限提高一倍。

例如

TINYINT 的儲存範圍是 -128 ~ 127 ,UNSIGNED TINYINT 可以儲存範圍是 0 ~ 255。

1.2 實數型別

實數是帶有小數部分的數字。

1. FLOAT （4位元組）
2. DOUBLE （8位元組）

FLOAT 和 DOUBLE 型別只支援使用標準的浮點運算進行近似計算。

DECIMAL 型別用於儲存精確的小數。

因為 CPU不支援對 DECIMAL 的直接計算，所以在 MySQL 5.0 以及更高版本中，MySQL伺服器自身實現了 DECIMAL 的高精度計算。相對而言，CPU直接支援原生浮點計算，所以浮點運算明顯更快。

因為需要額外的空間和計算開銷，所以應該儘量只在對小數進行精確計算時才使用DECIMAL—例如儲存財務資料。

但在資料量比較大的時候，可以考慮使用 BIGINT 代替 DECIMAL，將需要儲存的貨幣單位根據小數的位數乘以相應的倍數即可。

1.3 字串型別

varchar 和 char 是兩種最主要的字串型別。

varchar

varchar 型別用於儲存可變長字串，是最常見的字串資料型別。

它比定長型別更節省空間，因為它僅使用必要的空間（越短的字串使用越少的空間）。

varchar 需要1或2個額外位元組記錄字串的長度。

下面這些情況下使用 varchar是合適的：

1. 字串列的最大長度比平均長度大很多。
2. 列的更新很少，所以碎片不是問題。
3. 使用了像 UTF-8 這樣複雜的字符集，每個字元都使用不同的位元組數進行儲存。

char

char 型別是定長的： MySQL總是根據定義的字串長度分配足夠的空間。

下面這些情況下使用 varchar是合適的：

1. char適合儲存很短的字串，或者所有值都接近一個長度。（如密碼的MD5值，定長值）
2. 對於經常變更的資料，char也是比varchar更好，因為定長的char型別不容易產生碎片。
3. 對於非常短的列，char 比varchar在儲存空間上也更有效率。（如char(1)來儲存Y和N,只需要一個位元組，但是varchar(1)卻需要兩個位元組，因為還需要一個記錄長度的額外位元組）

與 char 和 varchar 類似的型別還有 binary 和 varbinary ，它們儲存的是二進位制字串。

使用 varchar(5) 和 varchar(200) 儲存“hello” 的空間開銷是一樣的。那麼使用更短的列有什麼優勢嗎？

事實上有很大的優勢。更長的列會消耗更多的記憶體，因為MySQL通常會分配固定大小的記憶體塊來儲存內部值。

尤其是使用記憶體臨時表進行排序或操作時會特別糟糕。所以，最好的策略是隻分配真正需要的空間。

blob 和 text 型別

blob 和 text 都是為儲存很大的資料而設計的字串資料型別，分別採用二進位制和字串方式儲存。

1.4 日期和時間型別

datetime

使用8個位元組的儲存空間。這個型別能儲存大範圍的值，從1001年到9999年，精度為秒。

timestamp

使用4個位元組的儲存空間。只能表示從1970年到2038年。

除特殊行為之外，通常應該儘量使用 timestamp，因為它比 datetime 空間效率更高。

如果需要儲存比秒更小粒度的日期和時間值怎麼辦？

那麼就可以使用BIGINT型別儲存微秒級別的時間戳。

1.5 位資料型別

MySQL有少數幾種儲存型別使用緊湊的位儲存資料。所有這些位型別，不管底層儲存格式和處理方式如何，比技術上來說都是字串型別。

BIT

MySQL 把 BIT 當作字串型別，而不是數字型別。當檢索 BIT(1) 的值時，結果是一個包含二進位制0或1值的字串，而不是 ASCII 碼的“0”或“1”。

應該謹慎使用 BIT 型別。對於大部分應用，最好避免使用這種型別。

SET

如果需要儲存很多 true/ false值，可以考慮合併這些列到一個SET 資料型別，它在 MySQL 內部是以一系列打包的位的集合來表示的。

1.6 選擇識別符號

選擇標識列的型別時，不僅僅需要考慮儲存型別，還需要考慮MySQL對這種型別怎麼執行計算和比較。

整數通常是標識列最好的選擇，因為它們很快並且可以使用 AUTO_INCREMENT.

如果可能，應該避免使用字串型別作為標識列，因為它們很消耗空間。

如果儲存 UUID 值，則應該移除“-”符號，或者更好的做法是，使用 UNHEX() 函式轉換 UUID 值為16位元組的數字，並且儲存在一個 BINARY(16)中，檢索時可以通過HEX() 函式來格式化為十六進位制格式。

IP地址，人們經常使用 varchar(15) 列來儲存 IP 地址。

然而，它們實際上是32位無符號整數，不是字串。用小數點將地址分為四段的表示方法也只是為了讓人們閱讀容易。

所以應該用無符號整數儲存IP地址。MySQL提供 INET_ATON() 和 INET_NTOA() 函式在這兩種表示方法之間轉換。

2. MySQL 資料庫設計中的陷阱

設計MySQL 的資料庫的問題。

不好的設計：

1. 太多列
2. 太多關聯
3. 過度使用列舉
4. 不要怕使用NULL

3. 正規化和反正規化

3.1 正規化

正規化的優點

1. 正規化化的更新操作通常比反正規化要快。
2. 當資料較好地正規化化時，就只有很少或者沒有重複資料，所以只需要修改更少的資料。
3. 正規化化的表通常更小，可以更好地放在記憶體裡，所以執行操作會更快。
4. 很少有多餘的資料意味著檢索列表資料時更少需要DISTINCT 或者 GROUP BY 語句。

正規化的缺點

1. 通常需要關聯。

3.2 反正規化

反正規化的優點

1. 反正規化化的資料都在一張表中，可以很好的避免關聯。

反正規化的缺點

1. 更新資料會變複雜。

3.3 混用正規化化和反正規化化

實際應用中經常需要混用。

最常見的反正規化化資料的方法是複製或者快取，在不同的表中儲存相同的特定列，也就是冗餘資料列，減少關聯表。

另一個從父表冗餘一些資料到子表的理由是排序的需要。

4. 快取表和彙總表

有時提升效能最好的方法是在同一張表中儲存衍生的冗餘資料。

然而，有時也需要建立一張完全獨立的彙總表或快取表（特別是滿足檢索的需求時）。

快取表：表示儲存那些可以比較簡單地從資料庫其它表獲取（但每次獲取的速度比較慢）資料的表。

彙總表：儲存的是使用 GROUP BY 語句聚合資料的表。

不嚴格的計數或通過小範圍查詢填滿間隙的嚴格計數，都比實時計算統計值速度快很多。

計數器表

如果應用在表中儲存計數器，則在更新計數器時可能碰到併發問題。

更快地讀，更慢的寫

為了提升讀查詢的速度，經常會需要建一些額外索引，增加冗餘列，甚至是建立快取表和彙總表。這些方法會增加寫查詢的負擔，也需要額外的維護任務，但在設計高效能資料庫時，這些都是常見的技巧：雖然寫操作變得更慢了，但更顯著地提高了讀操作的效能。

5. 加快ALTER TABLE 操作的速度

ALTER TABLE 操作的效能對大表來說是個大問題。

MySQL執行大部分修改表結構操作的方法是用新的結構建立一個空表，從舊錶中查出所有資料插入新表，然後刪除舊錶。這樣操作可能需要花費很長時間，如果記憶體不足而表又很大，而且還有很多索引的情況下尤其如此。

使用方法有兩種：

1. 先在一臺不提供服務的機器上執行ALTER TABLE操作，然後和提供服務的主庫進行切換。
2. 影子拷貝。用要求的表結構建立一張和源表無關的新表，然後通過重新命名和刪表操作交換兩張表。

6. 總結

良好的資料庫設計原則是普遍適用的，但MySQL有它自己的實現細節要注意。

概括來說，儘可能保持任何東西小而簡單總是好的。

MySQL喜歡簡單，需要使用資料庫的人應該也同樣喜歡簡單的原則：

1. 儘量避免過度設計，
2. 使用小而簡單的合適資料型別，除非真實資料模型中有確切的需要，否則應該儘可能避免使用NULL值。
3. 儘量使用相同的資料型別儲存相似或相關的值，尤其是要在關聯條件中使用的列。
4. 注意可變長字串，其在臨時表和排序時可能導致悲觀的按最大長度分配記憶體。
5. 儘量使用整型定義標識列。
6. 以免使用MySQL已經遺棄的特性，如指定浮點數的精度，或者整數的顯示寬度。
7. 小心使用ENUM和SET。最好避免使用BIT。

正規化是好的，但是反正規化有時也是必需的，並且能帶來好處。

最後，ALTER TABLE 是讓人痛苦的操作，因為在大部分情況下，它都會鎖表並且重建整張表。