物理設計
一、定義數據庫、表及字段的命名規範
數據庫、表及字段的命名要遵守可讀性原則、表意性原則、長名原則
二、選擇合適的存儲引擎
| 存儲引擎 | 事務 | 鎖粒度 | 主要應用 | 忌用 |
|---|---|---|---|---|
| InnoDB | 支持 | 支持MVCC的行級鎖 | 事務處理 | 無 |
| MyISAM | 不支持 | 支持併發插入的表級鎖 | select、insert | 讀寫操作頻繁 |
| MRG_MyISAM | 不支持 | 支持併發插入的表級鎖 | 分段歸檔，數據倉庫 | 全局查找過多的場景 |
| Archive | 不支持 | 行級鎖 | 日誌記錄，只支持insert、select | 需要隨機讀取、更新及刪除 |
| Ndb cluster | 支持 | 行級鎖 | 高可用性 | 大部分應用 |
三、爲表中的字段選擇合適的數據類型
1.原則
當一個列可以選擇多種數據類型是，應當優先考慮數字類型，其次是日期或二進制類型，最後是字符串類型。對於相同級別的數據類型，應該有效選擇佔用空間小的數據類型
數字類型 > 日期、二進制 > 字符串
2.整數類型
| 列類型 | 存儲空間 | 範圍（有符號） | 範圍（無符號） |
|---|---|---|---|
| tinyint | 1 字節 | -128 ~ 127 | 0 ~ 255 |
| smallint | 2 字節 | -32 768 ~ 32 767 | 0 ~ 65 535 |
| mediumint | 3 字節 | -8 388 608 ~ 8 388 607 | 0 ~ 16 777 215 |
| int/integer | 4 字節 | -2 147 483 648 ~ 2 147 483 647 | 0 ~ 4 294 967 295 |
| bigint | 8 字節 | -9 233 372 036 854 775 808 ~ 9 223 372 036 854 775 807 | 0 ~ 18 446 744 073 709 551 615 |
3.實數類型
| 列類型 | 存儲空間 | 是否精確 |
|---|---|---|
| float | 4 字節 | 否 |
| double | 8 字節 | 否 |
| decimal | 每4個字節存9個數字，小數點佔一個字節 | 是 |
4.VARCHER、CHAR 類型
utf8 字符集爲例，存儲10個字符的話列定義爲
VARCHAR(10)、CHAR(10)而不是、VARCHAR(30)CHAR(30)
a). VARCHAR類型的存儲特點
- varchar 用於存儲變長的字符串，只佔用必要的存儲空間
- 列的最大長度小於255則只佔用一個額外字節用於記錄字符串長度
- 列的最大長度大於255則要佔用兩個額外字節用於記錄字符創長度
b).VARCHAR、CHAR 類型的選擇
1.VARCHAR 的長度選擇
- 使用最小的符合需求的長度：MySQL 5.7 之前修改表結構需鎖表；5.7之後若原長度在255以內，且修改後長度也在255以內則不鎖表，否則同樣需要鎖表
- varchar(5)、varchar(200)存儲 “MySQL” 字符串性能不同：MySQL優化查詢時會使用固定寬度，例如創建查詢臨時表時，需要更多的內存
2.VARCHAR 的適用場景
- 字符串咧的最大長度比平均長度大很多
- 字符串列很少被更新
- 使用了utf8等多字節字符集存儲的字符串
3.CAHR 的特點
- CHAR 類型是定長的
- 字符串存儲在CHAR類型的列中會刪除末尾空格，VARCHAR不會刪除
- CHAR 類型的最大寬度爲255，超過則使用VARCHAR
4.CAHR 的適用場景
- 長度近似的值：手機號、身份證
- 短字符串：性別
- 經常更新的字符串：流轉狀態
4.日期數據
1.DATETIME 類型
- 以 YYYY-MM-DD HH:MM:SS[.fraction] 格式存儲日期時間
datetime = YYYY-MM-DD HH:MM:SS
datetime(6) = YYYY-MM-DD HH:MM:SS[.fraction] (存儲微秒)- DATETIME 類型與時區無關，佔用8個字節的存儲空間
- 時間範圍 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59
2.TIMESTAMP 類型
- 存儲由格林尼治時間1970年1月1日到當前時間的秒數
- 以 YYYY-MM-DD HH:MM:SS[.fraction] 的格式顯示
- 佔用4個字節，實際存儲爲
int- 時間範圍 1970-01-01 ~ 2038-01-19
- 顯示依賴於所指定的時區
- 在行的數據修改時可以自動修改
timestamp列的值，默認第一列timestamp可自動更新，也可通過建表語句指定：可用於記錄數據修改的時間
3.DATE、TIME類型（MySQL5.7 之後）
- DATE類型
- 佔用自己鵝湖比使用字符串、datetime、int 存儲要少，使用date類型只需要三個字節
- 使用DATE類型還可利用日期時間函數進行日期之間的計算
- 範圍 1000-01-01 ~ 9999-12-31
- TIME類型
- 用於存儲時間數據，格式爲 HH:MM:SS
4.注意事項
- 不要使用字符串類型來存儲日期時間數據：a.日期時間類型通常比字符串佔用的存儲空間小;b.日期時間類型在進行查找過濾時可以利用日期來進行對比;c.日期時間類型還有着豐富的處理喊出，可以方便的對其進行日期計算
- 使用int存儲日期時間不如使用timestamp類型：本身即爲int存儲，但是展示時更易讀
四、總結
如何爲InnoDB選擇主鍵?
- 主鍵應該儘可能的小：因爲每一個非主鍵索引都會附加主鍵的信息，如果我們主鍵非常大的話，會使索引變慢，影響查詢效率
- 主鍵應該是順序增長的：避免了隨機IO的產生，增加數據的插入效率。如果主鍵不能保證順序增長，則有可能每次插入後都有可能進行隨機排序，會帶來額外的IO消耗
- InnoDB的主鍵和業務主鍵可以不同：爲了保證業務主鍵的唯一性，可以設置唯一索引