1 命名規範mysql
普通索引：idx_字段名sql
惟一索引：ux_字段名數據庫
全部數據庫對象名稱必須使用小寫字母並用下劃線分割緩存
禁止使用mysql保留關鍵字 ---若是表名中包含關鍵字查詢時，須要將其有單引號括起來安全
見名識意，而且最後不要超過32個字符服務器
臨時庫表以tmp_爲前綴並以日期爲後綴，備份表以bak_爲前綴並以日期爲後綴mysql優化
全部存儲相同數據的列名和列類型必須一致--通常做爲關聯列，若是查詢時關聯列類型不一致會自動進行數據類型隱式轉換，會形成列上的索引失效，致使查詢效率下降併發
2 數據庫基本設計規範數據庫設計
沒有特殊要求下，全部表必須使用innodb存儲引擎--支付事務、行級鎖、更好的恢復性、高併發下性能更好函數
數據庫和表的字符集統一使用utf8---統一字符集能夠避免因爲字符集轉換產生的亂碼，不一樣的字符集進行比較前須要進行轉換會形成索引失效
全部表和字段都須要添加註釋--使用comment從句添加表和列的備註進行數據字典的維護
儘可能控制單表數據量的大小，建議控制在500萬之內，過大會形成修改表結構、備份、恢復都會有很大的問題。能夠用歷史數據歸檔應用於日誌數據，分庫分表應用於業務數據等手段
謹慎使用mysql分區表--分區表在物理上表現爲多個文件，在邏輯上表現爲一個表，跨分區查詢效率可能更低，建議採用物理分表的方式管理大數據
儘可能作到冷熱數據分離，減少表的寬度--mysql限制每一個表最多存儲4096列，而且每一行數據在大小不能超過65535字節 減小磁盤IO--保證熱數據的內存緩存命中率，避免讀入無用的冷數，常常一塊兒使用的列放到一個表中避免更多的關聯操做。
禁止在表中創建預留字段--沒法確認存儲的數據類型，對預留字段類型的修改會對錶進行鎖定
禁止在數據庫中存儲圖片，文件等大的二進制數據---IO操做耗時，一般存儲於文件服務器，數據庫只存儲文件地址信息
禁止在線上作數據庫壓力測試
禁止從開發環境、測試環境直接鏈接生成環境數據庫
2 數據庫字段設計規範
優先選擇符合存儲須要的最小的數據類型-- 字段大，創建索引空間大，IO次數多，索引性能差
1 將字符串轉換成數字類型存儲如：IP地址-插入數據前先用inet_aton把ip地址轉爲整型，節省空間，顯示數據時使用inet_ntoa把整型ip地址轉爲地址顯示便可
2 對於非負型的數據 如 自增id IP 要優先使用無符號整型來存儲，無符號相對於有符號能夠多出一倍的存儲空間
SIGNED INT -2147483648~2147483647
UNSIGNED INT 0~4294967295
VARCHAR(N)中的N表明的是字符數，而不是字節數
使用UTF8存儲255個漢字 Varchar(255)=765個字節。過大的長度會消耗更多的內存
避免使用text、blob數據類型，最多見的text類型能夠存儲64K的數據---能夠分離到單獨的擴展表中
mysql內存臨時表不支持text/blob大數據類型，若是查詢中包含這樣的數據，在排序等操做時，就不能使用內存臨時表，必須使用磁盤臨時表進行。mysql還要進行二次查詢，會使sql性能變得不好，不須要text列的數據時不要對該列進行查詢
text/blob類型只能使用前綴索引，而且text列上是不能有默認值的
避免使用enum類型--修改enum值須要使用alter語句-enum類型的order by 操做效率低，須要額外操做，禁止使用數值做爲enum的枚舉值
儘量把全部列定義爲not null--索引null列須要額外的空間來保存，因此要佔用更多的空間；進行比較和計算時要對null值作特別的處理
使用timestamp 4個字節 或 datetime類型8個字節 存儲時間
TIMESTAMP 存儲的時間範圍 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07。
TIMESTAMP 佔用4字節和INT相同，但比INT可讀性高
超出TIMESTAMP取值範圍的使用DATETIME類型存儲
同財務相關的金額數據必須使用decimal類型
非精準浮點：float,double
精準浮點：decimal
Decimal類型爲精準浮點數，在計算時不會丟失精度。佔用空間由定義的寬度決定，每4個字節能夠存儲9位數字，而且小數點要佔用一個字節。可用於存儲比bigint更大的整型數據。
4 索引設計規範
限制每張表上的索引數量，不超過5個，索引能夠增長查詢效率，一樣也會下降插入和更新的效率，有些狀況下會下降查詢效率
由於mysql優化器在選擇如何優化查詢時，會根據統一信息，對每個能夠用到的索引來進行評估，以生成出一個最好的執行計劃，若是同時有不少個索引均可以用於查詢，就會增長mysql優化器生成執行計劃的時間，一樣會下降查詢性能
禁止給表中的每一列都創建單獨的索引---使用聯合索引查詢
每一個索引組織表innodb必須有個主鍵--數據的存儲的邏輯順序和索引的順序是相同的，每一個表均可以有多個索引，可是表的存儲順序只能有一種innodb是按照主鍵索引的順序來組織表的。
不要使用更新頻繁的列做爲主鍵，不要使用uuid md5 hash 字符串列做爲主鍵--沒法保證數據的順序增長
主鍵建議使用自增ID值
5 常見索引列建議
出如今select update delete 語句的where 從句中的列
包含在order by group by distinct中的字段
多表join的關聯列
創建聯合索引效果更好
6 索引列的順序 -區分別最高的放在聯合索引的最左側 ，區分度=列中不一樣值的數量/列的總行數
儘可能把字段長度小的列放在聯合索引的左側
7 避免創建冗餘索引和重複索引
重複索引示例：primary key(id)、index(id)、unique index(id)
冗餘索引示例：index(a,b,c)、index(a,b)、index(a)
8 優先考慮覆蓋索引--就是包含了全部查詢字段（where select order bjy group by ）的索引
避免lnnodb表進行索引的二次查詢
9 索引規範
儘可能避免使用外鍵約束，但要在表與表之間的關聯鍵上創建索引，外鍵建議在業務端實現參照完整性
外鍵會影響父表和子表的寫操做從而下降性能
10 數據庫開發規範
建議使用預編譯語句進行數據庫操做-減小編譯所須要的時間，還能夠解決動態sql所帶來的sql注入問題 只傳參數，比傳遞sql語句更高效，相同語句能夠一次解析，屢次使用，提升處理效率
避免數據類型的隱式轉換 id=''
充分利用表上已經存在的索引-避免使用雙%號的查詢條件
一個sql只能利用到複合索引中的一列進行範圍查詢-如：有 a,b,c列的聯合索引，在查詢條件中有a列的範圍查詢，則在b,c列上的索引將不會被用到，在定義聯合索引時，若是a列要用到範圍查找的話，就要把a列放到聯合索引的右側
使用left join或 not exists來優化not in操做 由於not in 也一般會使用索引失效。
數據庫設計進，應要對之後擴展進行考慮
程序鏈接不一樣的數據庫使用不一樣的帳號，跨庫查詢
爲數據庫遷移和分庫分表留出餘地
下降業務耦合度
避免權限過大而產生的安全風險
禁止使用select * 使用select 字段 查詢
禁止使用不含字段一表的insert語句
避免使用子查詢，能夠把子查詢優化爲join操做 通用子查詢在in子句中，且子查詢中爲簡單sql進才能夠轉化爲關聯查詢進行優化
子查詢結果信沒法使用索引，一般子查詢的結果集會被存儲到臨時表中，不管是內存臨時表仍是磁盤臨時表都不會存在索引。
避免使用JOIN關聯太多的表－關聯緩存大小能夠由join_buffer_size參數進行設置，最多容許關聯61個表，建議不超過5個。
減小同數據庫的交互次數-批量操做合交多個相同的操做到一塊兒，能夠提升處理效率
對應同一列進行or判斷時，使用in代替or,in 的值不要超過500個，能夠更有效的利用索引，or不多能利用到索引
禁使用order by rand()進行隨機排序
where從句中禁止對列進行函數轉換和計算：沒法使用索引
在明顯不會有重複值時使用union all 而不是union
union 會把兩個結果集的全部數據放到臨時表中後再進行去重操做，union all 不會再對結果集進行去重操做
拆分複雜的大sql爲多個小sql:大sql邏輯上比較複雜，須要佔用大量cpu進行計算；mysql一個sql只能使用一個cpu進行計算，拆分的可能經過並行執行來提升處理效率
11 數據庫操做行爲規範
超100萬行的批量寫操做，要分批屢次進行操做；大批量寫操做產生大量日誌。特別是對於row格式。
大批量修改數據，必定是在一個事務中進行的，這就會形成表中大批量數據進行鎖定，從而致使大量的阻塞
對於大表使用pt-online-schema-change修改表結構：避免大表修改產生的主從延遲，避免在對錶字段進行修改時進行鎖表，pt-online-schema-change首先創建一個與原表結構相同的新表，而且在新表上進行表結構的修改，而後再把原表中的數據複製到新表中，並在原表中增長一些觸發器。把原表中新增的數據也複製到新表中，在行全部數據複製完成以後，把新表命名成原表，並把原表刪除掉。
禁止爲程序使用的帳號賦予super權限-只能留給DBA處理問題帳號使用。
對於程序鏈接數據庫帳號，遵循權限最小原則