規範適用場景：併發量大、資料量大的網際網路業務
（1）必須使用innodb儲存引擎
原因：支援事務、行級鎖、併發效能更好、cpu及記憶體快取頁優化使得資源利用率更高
（2）必須使用utf8字符集
原因：萬國碼，無需轉碼，無亂碼風險，節省空間
（3）資料表、資料字段必須加入中文注釋
原因：方便後來的人理解資料庫設計
（4）禁止使用儲存過程、檢視、觸發器、event
原因：高併發大資料的網際網路業務，架構設計思路是「解放資料庫cpu，將計算轉移到服務層」，併發量大的情況下，這些功能很可能將資料庫拖死，業務邏輯放到服務層具備更好的擴充套件性，能夠輕易實現「增機器就加效能」。資料庫擅長儲存與索引，cpu計算還是上移吧
（5）禁止儲存大檔案或者大**
原因：為何要讓資料庫做它不擅長的事情？大檔案和**儲存在檔案系統（oss），資料庫裡存uri就好
（6）只允許使用內網網域名稱，而不是ip連線資料庫
（7）線上環境、開發環境、測試環境資料庫內網網域名稱遵循命名規範
業務名稱：***
線上環境：***_prod
開發環境：***_dev
測試環境：***_test
從庫在名稱後加-s標識，備庫在名稱後加-ss標識
線上從庫：***_prod-s
線上備庫：***_prod-sss
（8）庫名、表名、欄位名：小寫，下劃線風格，不超過32個字元，必須見名知意，禁止拼音英文混用
（9）表名t_***，非唯一索引名idx_***，唯一索引名uniq_***
（10）單例項表數目必須小於500
（11）單表列數目必須小於30
（12）表必須有主鍵，例如自增主鍵
原因：a）主鍵遞增，資料行寫入可以提高插入效能，可以避免page**，減少表碎片提公升空間和記憶體的使用
b）主鍵要選擇較短的資料型別， innodb引擎普通索引都會儲存主鍵的值，較短的資料型別可以有效的減少索引的磁碟空間，提高索引的快取效率
c） 無主鍵的表刪除，在row模式的主從架構，會導致備庫夯住
（13）禁止使用外來鍵，如果有外來鍵完整性約束，需要應用程式控制
原因：外來鍵會導致表與表之間耦合，update與delete操作都會涉及相關聯的表，十分影響sql 的效能，甚至會造成死鎖。高併發情況下容易造成資料庫效能，大資料高併發業務場景資料庫使用以效能優先
（14）必須把字段定義為not null並且提供預設值
原因：a）null的列使索引/索引統計/值比較都更加複雜，對mysql來說更難優化
b）null 這種型別mysql內部需要進行特殊處理，增加資料庫處理記錄的複雜性；同等條件下，表中有較多空字段的時候，資料庫的處理效能會降低很多
c）null值需要更多的儲存空，無論是表還是索引中每行中的null的列都需要額外的空間來標識
d）對null 的處理時候，只能採用is null或is not null，而不能採用=、in、<、<>、!=、not in這些操作符號。如：where name!=』shenjian』，如果存在name為null值的記錄，查詢結果就不會包含name為null值的記錄
（15）禁止使用text、blob型別
（16）禁止使用小數儲存貨幣，必要時用bigdecimal高精度型別（精確到20位）
原因：使用整數（化分為整）吧，小數容易導致錢對不上。
（17）必須使用varchar(20)儲存手機號
原因：a）涉及到區號或者國家代號，可能出現+-()
b）手機號會去做數**算麼？
c）varchar可以支援模糊查詢，例如：like「138%」
（18）禁止使用enum，可使用tinyint代替
原因：a）增加新的enum值要做ddl操作
b）enum的內部實際儲存就是整數，你以為自己定義的是字串？
（19）單錶索引建議控制在5個以內
（20）單索引欄位數不允許超過5個
原因：字段超過5個時，實際已經起不到有效過濾資料的作用了
（21）禁止在更新十分頻繁、區分度不高的屬性上建立索引
原因：a）更新會變更b+樹，更新頻繁的字段建立索引會大大降低資料庫效能
b）「性別」這種區分度不大的屬性，建立索引是沒有什麼意義的，不能有效過濾資料，效能與全表掃瞄類似
（22）建立組合索引，必須把區分度高的字段放在前面
原因：能夠更加有效的過濾資料
（22.5）分庫分表時，查詢語句必須先限定分片鍵。
（23）禁止使用select *，只獲取必要的字段，需要顯示說明列屬性
原因：a）讀取不需要的列會增加cpu、io、net消耗
b）不能有效的利用覆蓋索引
c）使用select *容易在增加或者刪除欄位後出現程式bug
（24）禁止使用insert into t_*** values(***)，必須顯示指定插入的列屬性
原因：容易在增加或者刪除欄位後出現程式bug
（25）禁止使用屬性隱式轉換
原因：select uid from t_user where phone=13812345678 會導致全表掃瞄，而不能命中phone索引，猜猜為什麼？（這個線上問題不止出現過一次）
上面問題答案：phone定義為varchar型別了，在這裡phone會由字元型別隱式轉換為整型，（字元轉整型之後為0）。
（26）禁止在where條件的屬性上使用函式或者表示式
原因：select uid from t_user where from_unixtime(day)>='2017-02-15' 會導致全表掃瞄
正確的寫法是：select uid from t_user where day>= unix_timestamp('2017-02-15 00:00:00')
（27）禁止負向查詢，以及%開頭的模糊查詢
原因：a）負向查詢條件：not、!=、<>、!<、!>、not in、not like等，會導致全表掃瞄
b）%開頭的模糊查詢，會導致全表掃瞄
（28）禁止大表使用join查詢，禁止大表使用子查詢
原因：會產生臨時表，消耗較多記憶體與cpu，極大影響資料庫效能
（29）禁止使用or條件，必須改為in查詢
（30）應用程式必須捕獲sql異常，並有相應處理
總結：大資料量高併發的網際網路業務，極大影響資料庫效能的都不讓用，不讓用喲。
MySQL 資料庫規範 設計篇
1.設計階段 2.開發階段 3.調優階段 未開發，pt query digest show slow log 查詢優化等 4.福利彩蛋 1.1 資料庫表的設計正規化 三正規化 反正規化 為什麼需要正規化 優點 程式設計相對簡單，資料量更小，更適合放入記憶體，更新更快，只需要更新少量的資料，更少的冗餘...
資料庫開發規範參考
一.命名規範1.使用 innodb 儲存引擎 2.使據庫和表的字符集統一使用 utf8 字符集 3.所有的表和字段都要新增注釋 4.盡量控制單錶資料量控制在 500 萬行以內 5.謹慎使用 mysql 分割槽表 6.做到冷熱資料分離，減少表的寬度 7.禁止在表中建立預留字段 8.禁止在資料庫中儲存，...
MYSQL資料庫開發規範
自己總結的mysql開發規範，夠用就行了。1 表 1.1 表必須要有主鍵，主鍵使用自動遞增，型別為int。1.2 表名使用有意義的英文單詞，可用下劃線分割。如需使用縮寫時，不可使用意義不明的縮寫。1.3 需要多表join的字段，資料型別保持絕對一致。1.4 字段命名時需要加上表名，確保所有表中的字段...