資料庫設計規範建議

1 庫名

1. 【強制】庫的名稱必須控制在32個字元以內，相關模組的表名與表名之間儘量提現join的關係，如user表和user_login表。
2. 【強制】庫的名稱格式：業務系統名稱_子系統名，同一模組使用的表名儘量使用統一字首。
3. 【強制】一般分庫名稱命名格式是庫通配名_編號，編號從0開始遞增，比如wenda_001以時間進行分庫的名稱格式是"庫通配名_時間"
4. 【強制】建立資料庫時必須顯式指定字符集，並且字符集只能是utf8或者utf8mb4。建立資料庫SQL舉例：create database db1 default character set utf8;。

2 表結構

1. 【強制】表和列的名稱必須控制在32個字元以內，表名只能使用字母、數字和下劃線，一律小寫。
2. 【強制】表名要求模組名強相關，如師資系統採用"sz"作為字首，渠道系統採用"qd"作為字首等。
3. 【強制】建立表時必須顯式指定字符集為utf8或utf8mb4。
4. 【強制】建立表時必須顯式指定表儲存引擎型別，如無特殊需求，一律為InnoDB。當需要使用除InnoDB/MyISAM/Memory以外的儲存引擎時，必須通過DBA稽核才能在生產環境中使用。因為Innodb表支援事務、行鎖、宕機恢復、MVCC等關係型資料庫重要特性，為業界使用最多的MySQL儲存引擎。而這是其他大多數儲存引擎不具備的，因此首推InnoDB。
5. 【強制】建表必須有comment
6. 【建議】建表時關於主鍵：(1)強制要求主鍵為id，型別為int或bigint，且為auto_increment (2)標識表裡每一行主體的欄位不要設為主鍵，建議設為其他欄位如user_id，rder_id等，並建立unique key索引（可參考teacher表設計）。因為如果設為主鍵且主鍵值為隨機插入，則會導致innodb內部page分裂和大量隨機I/O，效能下降。
7. 【建議】核心表（如使用者表，金錢相關的表）必須有行資料的建立時間欄位create_time和最後更新時間欄位update_time，便於查問題。
8. 【建議】表中所有欄位必須都是NOT NULL屬性，業務可以根據需要定義DEFAULT值。因為使用NULL值會存在每一行都會佔用額外儲存空間、資料遷移容易出錯、聚合函式計算結果偏差等問題。
9. 【建議】建議對錶裡的blob、text等大欄位，垂直拆分到其他表裡，僅在需要讀這些物件的時候才去select。
10. 【建議】反正規化設計：把經常需要join查詢的欄位，在其他表裡冗餘一份。如user_name屬性在user_account，user_login_log等表裡冗餘一份，減少join查詢。
11. 【強制】中間表用於保留中間結果集，名稱必須以tmp_開頭。備份表用於備份或抓取源錶快照，名稱必須以bak_開頭。中間表和備份表定期清理。
12. 【強制】對於超過100W行的大表進行alter table，必須經過DBA稽核，並在業務低峰期執行。因為alter table會產生表鎖，期間阻塞對於該表的所有寫入，對於業務可能會產生極大影響。

3 列資料型別優化

1. 【建議】表中的自增列（auto_increment屬性），推薦使用bigint型別。因為無符號int儲存範圍為-2147483648~2147483647（大約21億左右），溢位後會導致報錯。
2. 【建議】業務中選擇性很少的狀態status、型別type等欄位推薦使用tinytint或者smallint型別節省儲存空間。
3. 【建議】業務中IP地址欄位推薦使用int型別，不推薦用char(15)。因為int只佔4位元組，可以用如下函式相互轉換，而char(15)佔用至少15位元組。一旦表資料行數到了1億，那麼要多用1.1G儲存空間。
4. SQL：select inet_aton('192.168.2.12'); select inet_ntoa(3232236044);
5. PHP: ip2long('192.168.2.12'); long2ip(3530427185);
6. 【建議】不推薦使用enum，set。 因為它們浪費空間，且列舉值寫死了，變更不方便。推薦使用tinyint或smallint。
7. 【建議】不推薦使用blob，text等型別。它們都比較浪費硬碟和記憶體空間。在載入表資料時，會讀取大欄位到記憶體裡從而浪費記憶體空間，影響系統性能。建議和PM、RD溝通，是否真的需要這麼大欄位。Innodb中當一行記錄超過8098位元組時，會將該記錄中選取最長的一個欄位將其768位元組放在原始page裡，該欄位餘下內容放在verflow-page裡。不幸的是在compact行格式下，原始page和verflow-page都會載入。
8. 【建議】儲存金錢的欄位，建議用int，程式端乘以100和除以100進行存取。因為int佔用4位元組，而double佔用8位元組，空間浪費。
9. 【建議】文字資料儘量用varchar儲存。因為varchar是變長儲存，比char更省空間。MySQL server層規定一行所有文字最多存65535位元組，因此在utf8字符集下最多存21844個字元，超過會自動轉換為mediumtext欄位。而text在utf8字符集下最多存21844個字元，mediumtext最多存224/3個字元，longtext最多存232個字元。一般建議用varchar型別，字元數不要超過2700。
10. 【建議】時間型別儘量選取timestamp。因為datetime佔用8位元組，timestamp僅佔用4位元組，但是範圍為1970-01-01 00:00:01到2038-01-01 00:00:00。更為高階的方法，選用int來儲存時間，使用SQL函式unix_timestamp()和from_unixtime()來進行轉換。

4 索引優化

1. 【強制】InnoDB表必須主鍵為id int/bigint auto_increment,且主鍵值禁止被更新。
2. 【建議】主鍵的名稱以"pk_"開頭，唯一鍵以"uk_"或"uq_"開頭，普通索引以"idx_"開頭，一律使用小寫格式，以表名/欄位的名稱或縮寫作為字尾。
3. 【強制】InnoDB和MyISAM儲存引擎表，索引型別必須為BTREE；MEMORY表可以根據需要選擇HASH或者BTREE型別索引。
4. 【強制】單個索引中每個索引記錄的長度不能超過64KB。
5. 【建議】單個表上的索引個數不能超過7個。
6. 【建議】在建立索引時，多考慮建立聯合索引，並把區分度最高的欄位放在最前面。如列userid的區分度可由select count(distinct userid)計算出來。
7. 【建議】在多表join的SQL裡，保證被驅動表的連線列上有索引，這樣join執行效率最高。
8. 【建議】建表或加索引時，保證表裡互相不存在冗餘索引。對於MySQL來說，如果表裡已經存在key(a,b)，則key(a)為冗餘索引，需要刪除。

5 分庫分表、分割槽表

1. 【強制】分割槽表的分割槽欄位（partition-key）必須有索引，或者是組合索引的首列。
2. 【強制】單個分割槽表中的分割槽（包括子分割槽）個數不能超過1024。
3. 【強制】上線前RD或者DBA必須指定分割槽表的建立、清理策略。
4. 【強制】訪問分割槽表的SQL必須包含分割槽鍵。
5. 【建議】單個分割槽檔案不超過2G，總大小不超過50G。建議總分割槽數不超過20個。
6. 【強制】對於分割槽表執行alter table操作，必須在業務低峰期執行。
7. 【強制】採用分庫策略的，庫的數量不能超過1024
8. 【強制】採用分表策略的，表的數量不能超過4096
9. 【建議】單個分表不超過500W行，ibd檔案大小不超過2G，這樣才能讓資料分散式變得效能更佳。
10. 【建議】水平分表儘量用取模方式，日誌、報表類資料建議採用日期進行分表。

6 字符集

1. 【強制】資料庫本身庫、表、列所有字符集必須保持一致，為utf8或utf8mb4。
2. 【強制】前端程式字符集或者環境變數中的字符集，與資料庫、表的字符集必須一致，統一為utf8。

7 程式層DAO設計建議

1. 【建議】新的程式碼不要用model，推薦使用手動拼SQL+繫結變數傳入引數的方式。因為model雖然可以使用面向物件的方式操作db，但是其使用不當很容易造成生成的SQL非常複雜，且model層自己做的強制型別轉換效能較差，最終導致資料庫效能下降。
2. 【建議】前端程式連線MySQL或者redis，必須要有連線超時和失敗重連機制，且失敗重試必須有間隔時間。
3. 【建議】前端程式報錯裡儘量能夠提示MySQL或redis原生態的報錯資訊，便於排查錯誤。
4. 【建議】對於有連線池的前端程式，必須根據業務需要配置初始、最小、最大連線數，超時時間以及連接回收機制，否則會耗盡資料庫連線資源，造成線上事故。
5. 【建議】對於log或history型別的表，隨時間增長容易越來越大，因此上線前RD或者DBA必須建立表資料清理或歸檔方案。
6. 【建議】在應用程式設計階段，RD必須考慮並規避資料庫中主從延遲對於業務的影響。儘量避免從庫短時延遲（20秒以內）對業務造成影響，建議強制一致性的讀開啟事務走主庫，或更新後過一段時間再去讀從庫。
7. 【建議】多個併發業務邏輯訪問同一塊資料（innodb表）時，會在資料庫端產生行鎖甚至表鎖導致併發下降，因此建議更新類SQL儘量基於主鍵去更新。
8. 【建議】業務邏輯之間加鎖順序儘量保持一致，否則會導致死鎖。
9. 【建議】對於單表讀寫比大於10:1的資料行或單個列，可以將熱點資料放在快取裡（如mecache或redis），加快訪問速度，降低MySQL壓力。

8 一個規範的建表語句示例

一個較為規範的建表語句為：

CREATETABLEuser ( `id`bigint(11) NOTNULL AUTO_INCREMENT, `user_id`bigint(11) NOTNULLCOMMENT '使用者id' `username`varchar(45) NOTNULLCOMMENT'真實姓名', `email`varchar(30) NOTNULLCOMMENT '使用者郵箱', `nickname`varchar(45) NOTNULLCOMMENT'暱稱', `avatar`int(11) NOTNULLCOMMENT'頭像', `birthday`dateNOTNULLCOMMENT'生日', `sex` tinyint(4) DEFAULT'0'COMMENT'性別', `short_introduce`varchar(150) DEFAULTNULLCOMMENT'一句話介紹自己，最多50個漢字', `user_resume`varchar(300) NOTNULLCOMMENT'使用者提交的簡歷存放地址', `user_register_ip`intNOTNULLCOMMENT '使用者註冊時的源ip', `create_time`timestampNOTNULLCOMMENT '使用者記錄建立的時間', `update_time`timestampNOTNULLCOMMENT '使用者資料修改的時間', `user_review_status` tinyint NOTNULLCOMMENT '使用者資料稽核狀態，1為通過，2為稽核中，3為未通過，4為還未提交稽核', PRIMARY KEY (`id`), UNIQUEKEY`idx_user_id` (`user_id`), KEY`idx_username`(`username`), KEY`idx_create_time`(`create_time`,`user_review_status`)) ENGINE=InnoDBDEFAULTCHARSET=utf8 COMMENT='網站使用者基本資訊';