1 命名規範
所有資料庫物件名稱必須使用小寫字母並用下劃線分割
禁止使用mysql保留關鍵字 ---如果表名中包含關鍵字查詢時，需要將其有單引號括起來
見名識意，並且最後不要超過32個字元
臨時庫表以tmp_為字首並以日期為字尾，備份表以bak_為字首並以日期為字尾
所有儲存相同資料的列名和列型別必須一致--一般作為關聯列，如果查詢時關聯列型別不一致會自動進行資料型別隱式轉換，會造成列上的索引失效，導致查詢效率降低
2 資料庫基本設計規範
沒有特殊要求下，所有表必須使用innodb儲存引擎--支付事務、行級鎖、更好的恢復性、高併發下效能更好
資料庫和表的字符集統一使用utf8---統一字符集可以避免由於字符集轉換產生的亂碼，不同的字符集進行比較前需要進行轉換會造成索引失效
所有表和字段都需要新增注釋--使用comment從句新增表和列的備註進行資料字典的維護
盡量控制單錶資料量的大小，建議控制在500萬以內，過大會造成修改表結構、備份、恢復都會有很大的問題。可以用歷史資料歸檔應用於日誌資料，分庫分表應用於業務資料等手段
謹慎使用mysql分割槽表--分割槽表在物理上表現為多個檔案，在邏輯上表現為乙個表，跨分割槽查詢效率可能更低，建議採用物理分表的方式管理大資料
盡量做到冷熱資料分離，減小表的寬度--mysql限制每個表最多儲存4096列，並且每一行資料在大小不能超過65535位元組 減少磁碟io--保證熱資料的記憶體快取命中率，避免讀入無用的冷數，經常一起使用的列放到乙個表中避免更多的關聯操作。
禁止在表中建立預留欄位--無法確認儲存的資料型別，對預留字段型別的修改會對錶進行鎖定
禁止從開發環境、測試環境直接連線生成環境資料庫
2 資料庫字段設計規範
優先選擇符合儲存需要的最小的資料型別-- 欄位大，建立索引空間大，io次數多，索引效能差
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處理問題賬號使用。
對於程式連線資料庫賬號，遵循許可權最小原則
mysql索引規範
摘要 主鍵索引名為 pk 欄位名 唯一索引名為 uk 欄位名 普通索引名則為 idx 欄位名 說明 pk 即 primary key uk 即 unique key 序號規範 說明例子 1 強制 業務上具有唯一特性的字段，即使是多個欄位的組合，也必須建成唯一索引。不要以為唯一索引影響了 insert...
mysql索引規範
索引並不是越多越好！索引可以提高查詢效率，但會降低增刪改效率。但多了甚至會降低查詢效率。innodb是按照主鍵索引的順序來組織表，如沒有建立主鍵，mysql會選擇第乙個非空唯一索引做為主鍵，或生成乙個佔6個位元組的主鍵，自動生成的主鍵效能並不是最好的，所以建立表時最好明確建立乙個主鍵 1 不使用更新...
mysql的庫命名規範 資料庫命名規範（命名規則）
資料庫命名規範 引言 資料庫設計過程中庫 表 欄位等的命名規範也算是設計規範的一部分，不過設計規範更多的是為了確保資料庫設計的合理性 為了專案最終的協調穩定性，而命名規範更多的是為了確保設計的正式和統一。資料庫中欄位等等以什麼樣的命名方式，並不會直接影響到專案的穩定性。制定規範的直接目的是約束行為，...