擴充閱讀
MySQL View
MySQL truncate table 與 delete 清空表的區別和坑
MySQL Ruler mysql 日常開發規範
MySQL datetime timestamp 以及如何自動更新，如何實現範圍查詢
MySQL 06 mysql 如何實現類似 oracle 的 merge into
MySQL 05 MySQL入門教程（MySQL tutorial book）
MySQL 04- EMOJI 表情與 UTF8MB4 的故事
MySQL Expression 1 of ORDER BY clause is not in SELECT list,references column
MySQL Ruler
寫在前面:
一、為何寫
為了自己以後的指令碼編寫或者是為團隊公司提供一個可以達成共識的標準。
二、怎麼定規範
簡潔明瞭。根據實際業務可以進行調整。每一個規定儘量描述清楚緣由。規範必須是不斷變化的,量體裁衣。
三、參考
《架構師之路》中有提及一些資料庫軍規。可以提供參考。
四、使用
解讀比規則本身更重要。
規範草案
基礎規範
適用於所有。(database, table, column)
1、必須有中文解釋
可以解釋到任何一個程式設計師(包括駭客)看到註釋後立刻理解其中的含義。而不是推敲其中的意思。為了保證這一點,衍生了第二條。
2、儘量使用英文,禁止中英文混用命名。
比如你看到了 zhrmghg 這個欄位然後覺得很深奧,後來問命名者告訴你是中華人民共和國的簡拼啊,你看不出來啊。。。
3、命名禁止出現大寫字母, 禁止出現_以外的字元。
必須保證命名規則轉換後可以符合比如駝峰命名。
4、禁止使用數字。使用英文單詞替代。
舉個例子 email_1, 那麼請重新命名為email_one。相信你可寫出0-99的英文單詞。避免,分不清l1, 分不清o0。
5、禁止使用雙引號對名稱引用, 避免大小寫敏感。
如果需要單詞間空格, 替換為下劃線。
6、所有的命名儘量指出欄位的業務含義。
如此之難,以至於想將這一條刪除。
資料庫規範
1、統一使用 UTF-8 編碼
無需轉碼,無亂碼風險。
2、資料庫命名與系統名稱保持一致。且必須滿足基礎規範。
比如專案名稱blog-service, 對應資料庫名稱 blog_service
表規範
1、如果是 MySQL, 請使用 InnoDB 引擎
支援事務。其他不吹不黑。
2、必須有主鍵。
如BIGINT(20)自增的ID, 有利於表的管理。但是這個ID未必是你的唯一約束主鍵。
3、禁止使用外來鍵。
所有的關聯使用應用程式去保證。
4、表名稱應統一使用t_開頭。
可以與普通的類區分開。當然這一點不強求。(很多公司做不到)
列規範
1、禁止列名使用 col等毫無意義的作為字首/字尾。
不要把名稱浪費在無用的事情上。
2、主鍵命名統一為id, 當然你也可以使其不包含任何業務含義。
不多說。
3、表中一般會包含2個欄位,建立時間和更新時間。請自行統一約定。
date 一般指日期, time 指時間。你可以約定為 created_time 和 updated_time。保證所有的 表統一。不要亂改名字。
4、所有的欄位都儘量設定為 NOT NULL
這一點根據業務而定。其實 null 不節約任何空間且會導致查詢效能最佳化變得困難。
5、禁止使用 TEXT、BLOB 此類較大的欄位
存放他的URL,對應的內容放在檔案伺服器中。
索引規範
1、單表索引不易過多。(5個以內為佳)
2、組合索引,區分度大的放在前面。
利於資料的快速過濾。
3、索引命名如下:
-
pk 主鍵 (primary key)
-
uk 唯一鍵 (unique key)
-
nk 普通索引 (normal key)
以上命名方式為字首。你會說為什麼不寫英文全拼啊 ? 不現實,總會有人寫錯。
SQL 使用規範
1、禁止使用 SELECT *, 必須指定需要查詢的欄位。
2、禁止使用 INSERT INTO t_xxx VALUES (XXX), 必須明確指定插入的列屬性
3、禁止全表掃描
可以看下 索引不工作的case, 實在無法避免可以和前端結合。比如查詢必須指定某一區分度很大的欄位才能查詢。
4、儘量不使用 JOIN
這一點很多人難以接受。處於效能無可厚非的規則。但是如果效能要求沒有這麼高,資源又有限,可不必遵循。