優秀的庫表設計是高效能資料庫的基礎。如何才能設計出高效能的庫表結構呢？這裡必須要提到資料庫正規化。正規化是基礎規範，反正規化是針對性設計。
正規化是設計資料庫結構過程中所要遵循的規則和指導方法
其實正規化有很多，目前關聯式資料庫有六種正規化：第一正規化（1nf）、第二正規化（2nf）、第三正規化（3nf）、巴斯-科德正規化（bcnf）、第四正規化(4nf）和第五正規化（5nf，又稱完美正規化）。滿足最低要求的正規化是第一正規化（1nf）。在第一正規化的基礎上進一步滿足更多規範要求的稱為第二正規化（2nf），其餘正規化以次類推。一般來說，資料庫只需滿足第三正規化(3nf）就行了。但是一般我們就用到前三個正規化
第一正規化(確保每列保持原子性)
第一正規化是最基本的正規化。如果資料庫表中的所有字段值都是不可分解的原子值，就說明該資料庫表滿足了第一正規化。
第一正規化的合理遵循需要根據系統的實際需求來定。比如某些資料庫系統中需要 用到「位址」這個屬性，本來直接將「位址」屬性設計成乙個資料庫表的字段就行。 但是如果系統經常會訪問「位址」屬性中的「城市」部分，那麼就
非要將「位址」這個屬 性重新拆分為省份、城市、詳細位址等多個部分進行儲存，這樣在對位址中某一 部分操作的時候將非常方便。這樣設計才算滿足了資料庫的第一正規化，如下表所 示。
上表所示的使用者資訊遵循了第一正規化的要求，這樣在對使用者使用城市進行分類的 時候就非常方便，也提高了資料庫的效能。
第二正規化(確保表中的每列都和主鍵相關)
第二正規化在第一正規化的基礎之上更進一層。第二正規化需要確保資料庫表中的每一 列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。 也就是說在乙個資料庫表中，乙個表中只能儲存一種資料，
不可以把多種資料 儲存在同一張資料庫表中。
比如要設計乙個訂單資訊表，因為訂單中可能會有多種商品，所以要將訂單編 號和商品編號作為資料庫表的聯合主鍵。
第三正規化(確保每列都和主鍵列直接相關,而不是間接相關)
第三正規化需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關。
比如在設計乙個訂單資料表的時候，可以將客戶編號作為乙個外來鍵和訂單表建立 相應的關係。而不可以在訂單表中新增關於客戶其它資訊（比如姓名、所屬公司 等）的字段。
總結：1nf：無重複的列，屬性不可以拆分（強調列的原子性，比如家庭**和個人**需要拆開）
2nf：屬性完全依賴於主鍵
3nf：屬性不傳遞依賴於其他非主屬性
優點：避免資料冗餘，減少資料的空間，資料變更速度更快
缺點：正規化等級越高，表的數量越多，獲取資料時表關聯過多，效能較差
正規化設計的表無法滿足效能需求時，需要根據業務場景，在正規化的基礎上靈活設計
1.業務場景
2.響應時間
3.欄位冗餘
想要發揮 mysql 的最佳效能，需要遵循 3 個基本使用原則。
1.回歸儲存的基本職能（mysql 資料庫只用於資料的儲存，不進行資料的複雜計算，不承載業務邏輯，確保儲存和計算分離）
2.查詢時盡量單錶查詢，減少跨庫查詢和多表關聯
3.杜絕大事務、大sql、大批量、大字段等效能殺手
大事務：執行步驟較多，涉及的表和字段較多，容易造成資源的爭搶，甚至形成死鎖。一旦事務回滾，會導致資源占用時間過長。
大 sql：複雜的 sql 意味著過多的表的關聯，mysql 資料庫處理關聯超過 3 張表以上的 sql 時，占用資源多，效能低下。
大批量：意味著多條 sql 一次性執行完成，必須確保進行充分的測試，並且在業務低峰時段或者非業務時段執行。
大字段：blob、text 等大字段，盡量少用。必須要用時，盡量與主業務表分離，減少對這類字段的檢索和更新。
下面具體講解資料庫的基本設定規則：
必須指定預設儲存引擎為 innodb，並且禁用 myisam 儲存引擎，隨著 mysql 8.0 版本的發布，所有的資料字典表都已經轉換成了 innodb，myisam 儲存引擎已成為了歷史。
預設字符集 utf8mb4，以前版本的 utf8 是 utf8mb3，未包含個別特殊字元，新版本的 utf8mb4 包含所有字元，官方強烈建議使用此字符集。
關閉區分大小寫功能。設定 lower_case_tables_name=1，即可關閉區分大小寫功能，即大寫字母 t 和小寫字母 t 一樣。
開啟 per-table 表空間，開啟後，每張業務表會單獨建立乙個獨立於系統表空間的表空間，便於空間的**，資料的遷移。
這裡在實踐中有個小問題，如何讓系統中區分大小寫的庫表轉換為不區分大小寫的庫表呢？因為要修改底層資料，還是比較麻煩的，操作步驟如下：
mysql dump 匯出資料庫。
修改引數 lower_case_tables_name=1。
匯入備份資料時，必須停止資料庫，停止業務，影響非常大。
禁用功能
mysql 資料庫提供的功能很全面，但並不是所有的功能效能都高效。
儲存過程、觸發器、檢視、event。為了儲存計算分離，這類功能盡量在程式中實現。這些功能非常不完整，除錯、排錯、監控都非常困難，相關資料字典也不完善，存在潛在的風險。一般在生產資料庫中，禁止使用。
lob、text、enum、set。這些字段型別，在 mysql 資料庫的檢索效能不高，很難使用索引進行優化。如果必須使用這些功能，一般採取特殊的結構設計，或者與程式結合使用其他的字段型別替代。比如：set 可以使用整型（0，1，2，3）、注釋功能和程式的檢查功能集合替代。
庫名：1位資料庫型別**+專案簡稱+識別**+序號
表名：
欄位名：
資料值進行參考
總結以高效能為目標，庫表設計以正規化為主，根據特殊業務場景使用反正規化，允許必要的空間換時間。
規範資料庫的使用原則，統一規範命名，減少效能隱患，減少隱式轉換。
高效能表設計的原則：合適的字段、合適的長度、not null。
從不同角度思考 ip、timestamp 的轉換，拓寬設計思路。
規範的命名可提高可讀性，反正規化設計可提高查詢效能。
如何設計資料庫
表與表之間的關係 例如下圖 假設使用者下單需要哪些表？每張表設計什麼字段，要用什麼型別 例如 建立個user表 create table t user id int 11 not null auto increment comment 使用者表id username varchar 50 not n...
如何設計資料庫 1 ？
為什麼需要設計資料庫 這裡我們思考兩個問題 修建茅屋需要設計嗎？修建大廈需要設計嗎？結論是 當資料庫比較複雜 如資料量大，表較多，業務關係複雜 時，我們需要先設計資料庫 因為，良好的資料庫設計能夠 q節省資料的儲存空間 q能夠保證資料的完整性 q方便進行資料庫應用系統的開發 糟糕的資料庫設計 q資料...
如何設計資料庫 2
資料規範化 僅有好的rdbms並不足以避免資料冗餘，必須在資料庫的設計中建立好的表結構。表設計後，很可能結構不合理，出現資料重複儲存，簡稱資料的冗餘，這對資料的增刪改查帶來很多後患，所以我們需要審核是否合理，就像施工圖設計後，還需要其他機構進行審核圖紙是否設計合理一樣。如何審核呢？需要一些有關資料庫...