【Web總結】數據庫系統

個人原文：www.hijerry.cn/p/6196.html

前言

數據也是Web應用最重要的部分，而數據庫剛好也是Web應用最容易出瓶頸的地方。通過幾年的學習、實踐我逐漸總結出了一套本身的數據庫設計、實踐原則，有一些是參考企業的，同時本身的優化方法也在裏面。

選擇合適的數據庫

Mysql是目前的主流數據庫之一，幾乎能夠承擔起全部Web站點的數據處理操做（經過集羣、主從等優化手段）。

大型應用會使用Oracel做爲數據庫（好比銀行、證券、電信）。

另外值得一提的是NOSQL，因爲它的靈活性高於關係型數據庫，因此經常使用於做爲緩存系統，如MemCache、Redis。

目前JS全棧流派會使用MongoDB做爲後臺數據庫。即使如此，我仍是推薦使用關係型數據庫做爲主數據庫，而NOSQL做爲輔助數據庫。

一些原則

如下的設計都是基於Mysql的。

範式和冗餘

關係型數據庫的範式有六種，這是理論上的。

在實際開發中，每每達到第三範式便可，並添加一些冗餘字段以方便查詢。

主外鍵

創建邏輯上的主外鍵，但不創建硬性的主外鍵關係。

邏輯上的主外鍵意味着主外鍵關係的維護交於程序來完成，而不是數據庫系統。這樣能夠避免主外鍵衝突而引發的沒必要要bug。

儘可能不使用組合主鍵。

字段類型和大小

在爲一個字段指定類型時，儘可能使用整數類型。由於查詢效率高，存儲空間小。

整數類型字段，儘可能使用 unsigned 。若是確實須要表示負數，那就用有符號的整數類型。

若是字段長度已知，務必使用char而不是varchar。varchar容易產生數據碎片，影響效率。好比存儲MD5哈希值。

儘可能避免可空字段，並給字段設置默認值。NULL 是一個很是噁心的東西，可能會引發索引分裂，而且有時候會引發意料以外的BUG。

索引

不要隨意創建索引，應當根據慢查詢創建適當的索引。好比常常須要排序、分組的字段，能夠創建索引。

把組合主鍵、值惟一的字段創建爲惟一索引。

儘可能使用數據量比較少的索引。好比在整數類型上創建，而不是在文本類型上。這也意味着，在對 text 等數據量比較大的字段創建索引時，應取字段的前面幾個字符創建索引便可，而不是創建全文索引。

儘可能選擇取值範圍更大的字段創建索引。好比咱們不該該在 性別字段上創建索引，由於它的取值太有限了。

儘可能擴展索引，而不是創建一個新的。好比已有索引(user_id)，如今要創建class_id的索引，能夠考慮創建爲(user_id, class_id)。

索引的創建是否恰當，最終取決於查詢速度是否提升了。因此建議根據慢查詢日誌來創建適當的索引。

編碼

儘可能使用utf8mb4編碼，這是四字節的UTF-8編碼，是符合標準意義的。而utf8編碼是用三字節存的，因此不能保存emoji表情。

查詢

儘可能避免大SQL查詢。

儘可能基於索引查詢。

比起構造一個複雜的SQL查詢作一次查詢，簡單、短小的基於索引的屢次查詢效率會更高。

實例：用戶表

這張表取自個人畢業設計，先看錶結構：

上面全部的整數類型都是 unsigned 類型的

• id 主鍵字段必有
• type 標識用戶類型。unsigned tinyint（0~255）足矣。
• login 登陸名。必須是變長的，由於這是用戶設置的，最多不超過 32 字符。
• telephone 手機號碼。也能夠用 bigint 存儲。也能夠用 char(11) 來存，也能夠用 char(13) 來存（區號2位），這裏用了 varchar(24) 是考慮到不一樣國家長度也不同，乾脆用變長字符來存了。
• email 郵箱地址。目前最長的郵箱是 32 字符，理論最長是 320 字符，這裏折中取了 128 字符。
• password 密碼。這裏是是使用 Hash:make 方法生成的，最長只有 60 位，因此長度是 60，而且爲了不編碼問題，使用 binary 字段來存儲。
• gender 性別。也可使用 enum 存儲，但強烈不推薦，更況且只是用來存儲整數形式的內容。因此直接用 tinyint 類型。
• register_ip 、last_login_ip 。ipv4地址。32 位的ipv4地址正好能夠用一個int類型保存。php裏使用ip2long函數便可完成轉換。若是遇到 ipv6 地址，就須要用 binary(16) 來存了。
• create_time 、 update_time 、delete_time 是Laravel框架所使用的用於記錄數據時間的字段，因此沒辦法設置爲了 能夠爲空。

看看索引：

UNIQUE KEY `type` (`type`,`login`)
複製代碼

這主要用於區分不一樣類型的用戶。