1 設計規範詳情mysql
1.1 基本命名和約束規範sql
1.1.1 統一表字符集爲UTF8,若是須要存儲emoj表情,須要使用UTF8mb4(mysql5.5.3之後才支持)數據庫
1.1.2 存儲引擎採用InnoDB函數
1.1.3 變長字符串儘可能使用varchar varbinary優化
1.1.4 不在數據庫中存儲圖片、文件等設計
1.1.5 單表數據量控制在1億如下索引
1.1.6 庫名、表名、字段名不使用保留字圖片
1.1.7 庫名、表名、字段名、索引名使用小寫字母,如下劃線分割 ,須要見名知意字符串
1.1.8 表名不宜設計過長,儘量用最少的字符表達出表的用途數學
1.2 字段設計規範
1.2.1 全部字段均定義爲NOT NULL
1.2.2 字段類型在知足需求條件下越小越好,使用UNSIGNED存儲非負整數 ,實際使用時候存儲負數場景很少
1.2.3 使用datatime類型存儲時間
1.2.4 使用varchar類型存儲變長字符串 ,固然要注意varchar(M)裏的M指的是字符數不是字節數;使用UNSIGNED INT存儲IPv4 地址而不是CHAR(15) ,這種方式只能存儲IPv4,存儲不了IPv6
1.2.5 使用DECIMAL存儲精確浮點數,用float有的時候會有問題
1.2.6 儘可能少用blob或text類型
1.3 索引設計規範
1.3.1 單個索引字段數不超過5,單表索引數量不超過5,索引設計遵循B+ Tree索引最左前綴匹配原則
1.3.2 選擇區分度高的列做爲索引
1.3.3 創建的索引能覆蓋80%主要的查詢,不求全,解決問題的主要矛盾
1.3.4 DML和order by和group by字段要創建合適的索引
1.3.5 避免索引的隱式轉換和避免冗餘索引
1.4 SQL設計規範
1.4.1 儘可能不使用存儲過程、觸發器、函數等
1.4.2 避免使用大表的JOIN,MySQL優化器對join優化策略過於簡單
1.4.3 避免在數據庫中進行數學運算和其餘大量計算任務
1.4.4 SQL合併,主要是指的DML時候多個value合併,減小和數據庫交互
1.4.5 合理的分頁,尤爲大分頁
1.4.6 UPDATE、DELETE語句不使用LIMIT ,容易形成主從不一致
1.5 補充說明
1.5.1 表字段爲何定義不使用Null
1.5.1.1 浪費存儲空間,由於InnoDB須要有額外一個字節存儲
1.5.1.2 表內默認值Null過多會影響優化器選擇執行計劃
1.5.2 關於使用datatime和timestamp
1.5.2.1 如今在5.6.4以後又有了變化,使用兩者存儲在存儲空間上大差距愈來愈小 ,而且自己datatime存儲範圍就比timestamp大不少,timestamp只能存儲到2038年