準備面試中學習的一些內容

六大約束

• 默認約束
• 非空約束 NOT NULL
• 主鍵約束
• 外鍵約束
• CHECK約束 mysql不支持
• UNIQUE約束

三大范式

• 屬性的原子性 字段內容不可再分解
• 記錄的唯一性 字段與字段之間不可存在部份依賴（學分依賴課程號，姓名依賴與學號）
• 字段的冗余性 一個字段不可由其他字段推算出來

表設計中忘記范式的原則

使用 BIGINT 的自增類型作為主鍵的設計僅僅適合非核心業務表，比如告警表、日志表等。真正的核心業務表，一定不要用自增鍵做主鍵，主要有 6 個原因：

• 自增存在回溯問題；
• 自增值在服務器端產生，存在并發性能問題；
• 自增值做主鍵，只能在當前實例中保證唯一，不能保證全局唯一；
• 公開數據值，容易引發安全問題，例如知道地址http://www.example.com/User/10/，很容猜出 User 有 11、12 依次類推的值，容易引發數據泄露；
• MGR（MySQL Group Replication） 可能引起的性能問題；
• 分布式架構設計問題。

推薦使用uuid作為主鍵
不過uuid是以時間低位為首，所以前四位會發生隨機的變化，并非單調遞增。而非隨機值在插入時會產生離散 IO，從而產生性能瓶頸。這也是 UUID 對比自增值最大的弊端。
MYSQL8.0以后出現了uuid-to-bin，實現以高位為首
優點：

• 以高位為首，沒有離散io，性能提高了
• 刪減了-分隔符
• 用二進制存儲，存儲空間由36字節（ e0ea12d4-6473-11eb-943c-00155dbaa39d）變為16字節（ 0x11EB6473E0EA12D4943C00155DBAA39D ）

分布式數據庫架構，僅用 UUID 做主鍵依然是不夠的。業務上建議在耦合一些業務相關的信息以及一個隨機碼。

數據庫表設計：

• 每張表一定要有一個主鍵；
• 自增主鍵只推薦用在非核心業務表，甚至應避免使用；
• 核心業務表推薦使用 UUID 或業務自定義主鍵；
• 一份數據應盡可能保留一份，通過主鍵關聯進行查詢，避免冗余數據；
• 在一些場景下，可以通過 JSON 數據類型進行反范式設計，提升存儲效率；