1. 使用Innodb儲存引擎

    5.5版本開始mysql預設儲存引擎就是InnoDB，5.7版本開始，系統表都放棄MyISAM了。

2. 表字符集統一使用UTF8

    •UTF8字符集儲存漢字佔用3個位元組，儲存英文字元佔用一個位元組

    •校對字符集使用預設的 utf8_general_ci

    •連線的客戶端也使用utf8，建立連線時指定charset或SET NAMES UTF8;。（對於已經在專案中長期使用latin1的，救不了         了）

    •如果遇到EMOJ等表情符號的儲存需求，可申請使用UTF8MB4字符集

3. 所有表都要添加註釋

    •儘量給欄位也添加註釋

    •類status型需指明主要值的含義，如”0-離線，1-線上”

4. 控制單表字段數量

    •單表字段數上限30左右，再多的話考慮垂直分表，一是冷熱資料分離，二是大欄位分離，三是常在一起做條件和返回列的不         分離。

    •表字段控制少而精，可以提高IO效率，記憶體快取更多有效資料，從而提高響應速度和併發能力，後續 alter table 也更快。

5. 所有表都必須要顯式指定主鍵

    •主鍵儘量採用自增方式，InnoDB表實際是一棵索引組織表，順序儲存可以提高存取效率，充分利用磁碟空間。還有對一些復       雜查詢可能需要自連線來優化時需要用到。

    •需要全域性唯一主鍵時，使用外部發號器ticket server（建設中）

    •如果沒有主鍵或唯一索引，update/delete是通過所有欄位來定位操作的行，相當於每行就是一次全表掃描

    •少數情況可以使用聯合唯一主鍵，需與DBA協商

6. 不強制使用外來鍵參考

    •即使2個表的欄位有明確的外來鍵參考關係，也不使用 FOREIGN KEY ，因為新紀錄會去主鍵表做校驗，影響效能。

7. 適度使用儲存過程、檢視，禁止使用觸發器、事件

    •儲存過程（procedure）雖然可以簡化業務端程式碼，在傳統企業寫複雜邏輯時可能會用到，而在網際網路企業變更是很頻                  繁 的，在分庫分表的情況下要升級一個儲存過程相當麻煩。又因為它是不記錄

    ·使用檢視一定程度上也是為了降低程式碼裡SQL的複雜度，但有時候為了檢視的通用性會損失效能（比如返回不必要的字               段）。

    •觸發器（trigger）也是同樣，但也不應該通過它去約束資料的強一致性，mysql只支援“基於行的觸發”，也就是說，觸發器         始終是針對一條記錄的，而不是針對整個sql語句的，如果變更的資料集非常大的話，效率會很低。掩蓋一條sql背後的工             作， 一旦出現問題將是災難性的，但又很難快速分析和定位。再者需要ddl時無法使用pt-osc工具。放在transaction執 行。

    •事件（event）也是一種偷懶的表現，目前已經遇到數次由於定時任務執行失敗影響業務的情況，而且mysql無法對它做失敗       預警。建立專門的 job scheduler 平臺。

8. 單表資料量控制在5000w以內

9. 資料庫中不允許儲存明文密碼