MySQL 數據表優化設計（六）：常見的數據表設計誤區整理

雖然會有一些常規意義上的數據表錯誤設計和優秀設計原則，但是同樣也會有 MySQL 特定的一些情況，這會導致我們犯一些 MySQL 特定的錯誤。本篇討論常見的設計誤區。

誤區一：過多的數據列

MySQL 存儲引擎的 API 是按照行緩衝區方式從服務端和存儲引擎複製數據。服務端將緩衝區數據解碼成數據列。然而，將行緩衝區的格式轉換爲數據行數據結構的列可能會代價很高。MyISAM 固定使用與服務端匹配的行格式，因此無需轉換。然而，MyISAM 的可變行格式以及 InnoDB 的行格式總是需要進行轉換。轉換的代價依賴於列的數量。如果當數據表的列超過上百列的時候，會引起很高的 CPU 資源消耗——即便是使用到的列很少。曾經看過一篇文章，指的是一個多語言的解決方案，直接簡單粗暴地將系統支持的語言用對應的列表示，例如：

CREATE TABLE t_multi_language_news (
  id INT PRIMARY KEY,
  title_cn VARCHAR(32),
  title_en VARCHAR(32),
  title_it VARCHAR(32),
  ...
  content_cn VARVHAR(256),
  content_en VARCHAR(256),
  conntent_it VARCHAR(256),
);

這種方式隨着系統支持的語言越多，數據表的列越多，最終導致性能嚴重下降。如果你設計一個數據表的列數量超過100時，就需要考慮你的設計是否合理了。
應對方式：首先是考慮業務本身的設計是否合理，如果確實一個實體需要很多字段來描述，那麼可以拆分數據表，通過擴展信息表來做。舉個例子，對於資訊類的數據表，因爲內容一般佔據的空間會比較大，但是在列表不會直接查看，就可以拆成資訊主表和資訊詳情表，主表存儲標題、時間、摘要、縮略圖附件 id 等列表要查看的信息即可。而資訊詳情可以存儲資訊的內容、來源、原文鏈接等信息。

誤區二：過多的聯合查詢

MySQL 一次聯合查詢最多隻能61張表。而有些設計主張不做冗餘字段設計，這會導致複雜業務時需要連接多張表查詢。即便是聯合的表數量低於61個，也會引起性能的下降，而且整個 SQL 語句的維護將變得十分困難。作爲一個設計的首要原則，就是如果想追求速度的話，一次查詢不要跨太多的數據表做聯合查詢，尤其面臨高併發場景的時候。
應對方式：首先，對於確定不會改變的字段，可以考慮冗餘字段的方式減少聯合查詢。例如，一家企業的所屬省份信息，就可以把省份代碼、省份名稱冗餘了，而無需再通過省份代碼去查詢省份名稱。其次，確實需要查其他表的情況下，可以考慮使用分步查詢的方法，通過應用程序完成數據的組裝，這種效率在數據表很多的時候會更高效，而且代碼也更好維護。
誤區三：萬能的枚舉
例如下面這種表設計：

CREATE TABLE t_countries (
  ...
  country ENUM('', '1', '2', ..., '45'),
  ...
);

這種方式本來可以通過一個以整數爲 key的字典的查找表實現。如果是業務上增加了一個枚舉，意味着整個表都需要使用 ALTER TABLE更新。而如果是使用應用代碼的查找表，只需要增加新的鍵值對就好了。
應對方式：如果枚舉確定不會變動（例如性別），那麼沒問題。如果枚舉可能會增加，那麼儘可能地通過應用程序來實現。

誤區三：濫用 SET替代 ENUM

枚舉ENUM 類型是數據表列的值只能是值集合中的一個，而 SET 類型是該列可以有一個或多個值。如果確定一個列只會有一個值，那麼就應該優先使用枚舉，而不是集合。例如下面的例子就是典型的濫用：

CREATE TABLE t_payment_way (
  ...
  is_default SET('Y', 'N') NOT NULL DEFAULT 'N',
  ...
);

很顯然，is_default 要麼是 Y，要麼是 N，因此這裏應該使用 ENUM。
應對方式：從業務層面考慮列的值是不是可能有多個，如果只有1個可選值那麼就用 枚舉ENUM。

誤區四：生硬地避免NULL

很多文章都討論過儘可能地避免使用 NULL，對於大部分場景這是一個好的設計，我們可以通過0，空字符串，約定的值等來表示空值。然而，不要因爲這個而生硬套用，如果是這個值本身就是一個無意義的值的時候，那麼使用 NULL 可能更合適。例如，如果要是有-1代表一個無意義的整數，可能會導致代碼很複雜，甚至可能引起 bug。例如下面的例子：

CREATE TABLE t_person (
  birthday DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  ...,
);

將一個 DATETIME 類型的默認值設置爲全部是0會很奇怪，假設我們要統計人員的年齡平均值的時候，會引起莫名其妙的問題，而這種場景使用 NULL 就不會納入到統計中來。可以通過設置 MySQL 的 SQL_MODE 參數禁止使用無意義的日期，避免出現這種情況。
應對方式：設計表的時候可以儘量使用 NOT NULL 避免空值，但是不要過於生硬，對於有些字段使用默認值無法表名意義或與實際不符時，也是可以選擇使用 NULL 列的。只是，需要注意索引列不要使用NULL。而實際上，絕大部分索引列不太可能會是 NULL。

誤區五：使用整數替換時間戳

之前有講到過時間格式如何選擇的問題，實際上有些開發者會使用整數來存儲時間戳，他們的理由是這樣效率更高。從某種意義上來說，可能會提高一點效率，但是幫助不大，因爲在 MySQL 內部DATETIME 和 TIMESTAMP 本身就是用整數存儲的。而如果使用整數存儲時間的話，意味着應用程序中需要做時間轉換，或者是 SQL 語句要對指定的字段進行時間轉換，帶來的收益可能得不償失。
應對方式：儘可能地使用 DATETIME 存儲時間，如果需要存儲秒級精度一下的時間，那麼可以考慮使用 BIGINT 來存儲。

誤區六：忘記字段的最大存儲範圍

在實際中設計表的時候會忘記數據類型的存儲範圍，比如使用 TINYINT(2)並不是只能存儲兩位整數，實際TINYINT(2) 可以存儲的範圍是-128-127。 存儲超過255的整數。這種錯誤在使用整數類型的時候很容易出現問題，在插入整數的時候，MySQL 不會檢查實際的整數位數，而是按對應存儲字節數的範圍存入，這種情況假設不注意會存入無意義的值。例如下面的 INSERT 操作會成功，而我們可能誤以爲 TINYINT(2)只能存儲2位整數：

CREATE TABLE t_int_test (
    id INT PRIMARY KEY,
    number TINYINT(2)
);

INSERT INTO t_int_test (id, number) VALUES (3,123);

應對方式：在應用程序中做數據校驗。

結語：在實際設計數據表的過程中，除了需要考慮每個字段的數據類型之外，還需要考慮存儲空間大小。對於常用的一些字段，如時間、標題、備註等，最好是內部形成一定的規範，大家遵照規範執行，並且增加校驗能夠避免很多問題。