《阿里開發手冊》總結

目錄

一. 編程規約
二. 異常日誌
三. MySQL數據庫
四. 工程結構
五. 安全規約

1、 編程規約

• (一)接口方法定義

  1. 接口類中的方法和屬性不要加任何修飾符號（public 也不要加）

• (二)命名規則

  1. Service/DAO 層方法命名規約
     1） 獲取單個對象的方法用 get 作前綴。
     2） 獲取多個對象的方法用 list 作前綴。
     3） 獲取統計值的方法用 count 作前綴。
     4） 插入的方法用 save（推薦） 或 insert 作前綴。
     5） 刪除的方法用 remove（推薦） 或 delete 作前綴。
     6） 修改的方法用 update 作前綴。

2. 領域模型命名規約
   1） 數據對象： xxxDO， xxx 即爲數據表名。
   2） 數據傳輸對象： xxxDTO， xxx 爲業務領域相關的名稱。
   3） 展現對象： xxxVO， xxx 通常爲網頁名稱。
   4） POJO 是 DO/DTO/BO/VO 的統稱，禁止命名成 xxxPOJO。

• (三)常量定義

  1. 【強制】 long 或者 Long 初始賦值時，必須使用大寫的 L，不能是小寫的 l，小寫容易跟數字
     1 混淆，形成誤解。
     說明： Long a = 2l; 寫的是數字的 21，仍是 Long 型的 2?

2. 【強制】單行字符數限制不超過 120 個，超出須要換行，換行時遵循以下原則：
   1） 第二行相對第一行縮進 4 個空格，從第三行開始，再也不繼續縮進，參考示例。
   2） 運算符與下文一塊兒換行。
   3） 方法調用的點符號與下文一塊兒換行。
   4） 在多個參數超長， 在逗號後換行。
   5） 在括號前不要換行
3. 【強制】 IDE 的 text file encoding 設置爲 UTF-8; IDE 中文件的換行符使用 Unix 格式，不要使用 windows 格式
4. 【推薦】方法體內的執行語句組、變量的定義語句組、不一樣的業務邏輯之間或者不一樣的語義之間插入一個空行。相同業務邏輯和語義之間不須要插入空行。
   說明： 沒有必要插入多個空行進行隔開

• (四)OOP 規約

  1. 【強制】全部的覆寫方法，必須加@Override 註解。
     說明： getObject()與 get0bject()的問題。一個是字母的 O，一個是數字的 0，加@Override能夠準確判斷是否覆蓋成功。另外，若是在抽象類中對方法簽名進行修改，其實現類會立刻編譯報錯
  2. 【強制】 相同參數類型，相同業務含義，纔可使用 Java 的可變參數，避免使用 Object。
     說明： 可變參數必須放置在參數列表的最後（提倡儘可能不用可變參數編程）
  3. 【強制】外部正在調用或者二方庫依賴的接口，不容許修改方法簽名，避免對接口調用方產生影響。接口過期必須加@Deprecated 註解，並清晰地說明採用的新接口或者新服務是什麼
  4. 【強制】不能使用過期的類或方法。
     說明： java.net.URLDecoder 中的方法 decode(String encodeStr) 這個方法已通過時，應該使用雙參數 decode(String source, String encode)。接口提供方既然明確是過期接口，那麼有義務同時提供新的接口； 做爲調用方來講，有義務去考證過期方法的新實現是什麼
  5. 【強制】 Object 的 equals 方法容易拋空指針異常，應使用常量或肯定有值的對象來調用equals。
     正例： 「test」.equals(object);
     反例： object.equals(「test」);
     說明： 推薦使用 java.util.Objects#equals （JDK7 引入的工具類）

6. 【強制】全部的相同類型的包裝類對象之間值的比較，所有使用 equals 方法比較。
   說明： 對於 Integer var = ? 在-128 至 127 範圍內的賦值， Integer 對象是在IntegerCache.cache 產生，會複用已有對象，這個區間內的 Integer 值能夠直接使用==進行判斷，可是這個區間以外的全部數據，都會在堆上產生，並不會複用已有對象，這是一個大坑，推薦使用 equals 方法進行判斷。
   舉例: Integer a = 1;Integer b = 1; a == b ; //true
   Integer a = 128;Integer b = 128; a == b ; //false
   Integer a = 128;Integer b = 128; a.equals(b) ; //true
   7. 關於基本數據類型與包裝數據類型的使用標準以下：
      1） 【強制】 全部的 POJO 類屬性必須使用包裝數據類型。
      2） 【強制】 RPC 方法的返回值和參數必須使用包裝數據類型。
      3） 【推薦】 全部的局部變量使用基本數據類型。
      說明： POJO 類屬性沒有初值是提醒使用者在須要使用時，必須本身顯式地進行賦值，任何NPE 問題，或者入庫檢查，都由使用者來保證。
      正例： 數據庫的查詢結果多是 null，由於自動拆箱，用基本數據類型接收有 NPE 風險。阿里巴巴 Java 開發手冊——禁止用於商業用途，違者必究—— 7 / 33
      反例： 好比顯示成交總額漲跌狀況，即正負 x%， x 爲基本數據類型，調用的 RPC 服務，調用不成功時， 返回的是默認值，頁面顯示： 0%，這是不合理的，應該顯示成中劃線-。因此包裝類型的 null 值，可以表示額外的信息，如：遠程調用失敗，異常退出
   8. 【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性默認值。
      反例： POJO 類的 gmtCreate 默認值爲 new Date();可是這個屬性在數據提取時並無置入具體值，在更新其它字段時又附帶更新了此字段，致使建立時間被修改爲當前時間
   9. 【強制】構造方法裏面禁止加入任何業務邏輯，若是有初始化邏輯，請放在 init 方法中
   10. 【強制】 POJO 類必須寫 toString 方法。使用 IDE 的中工具： source> generate toString時，若是繼承了另外一個 POJO 類，注意在前面加一下 super.toString。
       說明： 在方法執行拋出異常時，能夠直接調用 POJO 的 toString()方法打印其屬性值，便於排查問題。
   11. 【推薦】使用索引訪問用 String 的 split 方法獲得的數組時，需作最後一個分隔符後有無內容的檢查，不然會有拋 IndexOutOfBoundsException 的風險
   12. 【推薦】當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一塊兒，便於閱讀
   13. 【推薦】 類內方法定義順序依次是：公有方法或保護方法 > 私有方法 > getter/setter方法
   14. 【推薦】 setter 方法中，參數名稱與類成員變量名稱一致， this.成員名 = 參數名。在getter/setter 方法中， 不要增長業務邏輯，增長排查問題的難度
   15. 【推薦】類成員與方法訪問控制從嚴：
       1） 若是不容許外部直接經過 new 來建立對象，那麼構造方法必須是 private。
       2） 工具類不容許有 public 或 default 構造方法。
       3） 類非 static 成員變量而且與子類共享，必須是 protected。
       4） 類非 static 成員變量而且僅在本類使用，必須是 private。
       5） 類 static 成員變量若是僅在本類使用，必須是 private。
       6） 如果 static 成員變量，必須考慮是否爲 final。
       7） 類成員方法只供類內部調用，必須是 private。
       8） 類成員方法只對繼承類公開，那麼限制爲 protected。
       說明： 任何類、方法、參數、變量，嚴控訪問範圍。過於寬泛的訪問範圍，不利於模塊解耦。
       思考：若是是一個 private 的方法，想刪除就刪除，但是一個 public 的 service 方法，或者一個 public 的成員變量，刪除一下，不得手心冒點汗嗎？變量像本身的小孩，儘可能在本身的視線內，變量做用域太大，若是無限制的處處跑，那麼你會擔憂的。

• (五)集合處理

  1. 【強制】 關於 hashCode 和 equals 的處理，遵循以下規則：
     1） 只要重寫 equals，就必須重寫 hashCode。
     2） 由於 Set 存儲的是不重複的對象，依據 hashCode 和 equals 進行判斷，因此 Set 存儲的對象必須重寫這兩個方法。
     3） 若是自定義對象作爲 Map 的鍵，那麼必須重寫 hashCode 和 equals。
     說明： String 重寫了 hashCode 和 equals 方法，因此咱們能夠很是愉快地使用 String 對象做爲 key 來使用。
  2. 【強制】 ArrayList的subList結果不可強轉成ArrayList，不然會拋出 ClassCastException
     異常： java.util.RandomAccessSubList cannot be cast to java.util.ArrayList ;
     說明： subList 返回的是 ArrayList 的內部類 SubList，並非 ArrayList ，而是ArrayList 的一個視圖，對於 SubList 子列表的全部操做最終會反映到原列表上
  3. 【強制】 在 subList 場景中， 高度注意對原集合元素個數的修改，會致使子列表的遍歷、增長、刪除均產生 ConcurrentModificationException 異常。
  4. 【強制】使用集合轉數組的方法，必須使用集合的 toArray(T[] array)，傳入的是類型徹底同樣的數組，大小就是 list.size()。
     說明： 使用 toArray 帶參方法，入參分配的數組空間不夠大時， toArray 方法內部將從新分配內存空間，並返回新數組地址； 若是數組元素大於實際所需，下標爲[ list.size() ]的數組元素將被置爲 null，其它數組元素保持原值，所以最好將方法入參數組大小定義與集合元素個數一致。
     正例：
     List list = new ArrayList(2);
     list.add(「guan」);
     list.add(「bao」);
     String[] array = new String[list.size()];
     array = list.toArray(array);
     反例： 直接使用 toArray 無參方法存在問題，此方法返回值只能是 Object[]類，若強轉其它類型數組將出現 ClassCastException 錯誤。
  5. 【強制】使用工具類 Arrays.asList()把數組轉換成集合時，不能使用其修改集合相關的方法，它的 add/remove/clear 方法會拋出 UnsupportedOperationException 異常。
     說明： asList 的返回對象是一個 Arrays 內部類，並無實現集合的修改方法。Arrays.asList體現的是適配器模式，只是轉換接口，後臺的數據還是數組。
     String[] str = new String[] { 「a」, 「b」 };
     List list = Arrays.asList(str);
     第一種狀況： list.add(「c」); 運行時異常。
     第二種狀況： str[0] = 「gujin」; 那麼 list.get(0)也會隨之修改。
  6. 【強制】不要在 foreach 循環裏進行元素的 remove/add 操做,不然會報錯。 remove 元素請使用 Iterator方式，若是併發操做，須要對 Iterator 對象加鎖。
  7. 【強制】 在 JDK7 版本及以上， Comparator 要知足以下三個條件，否則 Arrays.sort，Collections.sort 會報 IllegalArgumentException 異常。
     說明：
     1） x， y 的比較結果和 y， x 的比較結果相反。
     2） x>y， y>z， 則 x>z。
     3） x=y， 則 x， z 比較結果和 y， z 比較結果相同。
  8. 【推薦】集合初始化時， 指定集合初始值大小。
     說明： HashMap 使用 HashMap(int initialCapacity) 初始化，
     正例：initialCapacity = (須要存儲的元素個數 / 負載因子) + 1。注意負載因子（即 loaderfactor） 默認爲 0.75， 若是暫時沒法肯定初始值大小， 請設置爲 16
  9. 【推薦】使用 entrySet 遍歷 Map 類集合 KV，而不是 keySet 方式進行遍歷。
     說明： keySet 實際上是遍歷了 2 次，一次是轉爲 Iterator 對象，另外一次是從 hashMap 中取出key 所對應的 value。而 entrySet 只是遍歷了一次就把 key 和 value 都放到了 entry 中，效率更高。若是是 JDK8，使用 Map.foreach 方法
  10. 【推薦】高度注意 Map 類集合 K/V 能不能存儲 null 值的狀況，以下：
      集合類 Key Value Super 說明
      Hashtable 不容許爲 null 不容許爲 null Dictionary 線程安全
      ConcurrentHashMap 不容許爲 null 不容許爲 null AbstractMap 分段鎖技術
      TreeMap 不容許爲 null 容許爲 null AbstractMap 線程不安全
      HashMap 容許爲 null 容許爲 null AbstractMap 線程不安全
  11. 【參考】合理利用好集合的有序性(sort)和穩定性(order)，避免集合的無序性(unsort)和不穩定性(unorder)帶來的負面影響。
      說明： 有序性是指遍歷的結果是按某種比較規則依次排列的。
      穩定性指集合每次遍歷的元素次序是必定的。
      如： ArrayList 是 order/unsort；
      HashMap 是 unorder/unsort；
      TreeSet 是order/sort。
  12. 【參考】利用 Set 元素惟一的特性，能夠快速對一個集合進行去重操做，避免使用 List 的contains 方法進行遍歷、對比、 去重操做

• (六)併發處理

  1. 【強制】 獲取單例對象須要保證線程安全，其中的方法也要保證線程安全。
     說明： 資源驅動類、工具類、單例工廠類都須要注意
  2. 【強制】建立線程或線程池時請指定有意義的線程名稱，方便出錯時回溯。
  3. 【強制】 SimpleDateFormat 是線程不安全的類，通常不要定義爲 static 變量，若是定義爲static，必須加鎖，或者使用 DateUtils 工具類
  4. 【強制】對多個資源、數據庫表、對象同時加鎖時，須要保持一致的加鎖順序，不然可能會形成死鎖。
  5. 【強制】併發修改同一記錄時，避免更新丟失， 須要加鎖。 要麼在應用層加鎖， 要麼在緩存加鎖，要麼在數據庫層使用樂觀鎖，使用 version 做爲更新依據。
     說明： 若是每次訪問衝突機率小於 20%，推薦使用樂觀鎖，不然使用悲觀鎖。樂觀鎖的重試次數不得小於 3 次。
  6. 【參考】 volatile 解決多線程內存不可見問題。
     對於一寫多讀，是能夠解決變量同步問題，可是若是多寫，一樣沒法解決線程安全問題。
     若是是 count++操做，使用以下類實現：
     AtomicInteger count = new AtomicInteger(); count.addAndGet(1);
     若是是 JDK8，推薦使用 LongAdder 對象，比 AtomicLong 性能更好（減小樂觀鎖的重試次數） 。
  7. 【參考】 HashMap 在容量不夠進行 resize 時因爲高併發可能出現死鏈，致使 CPU 飆升，在開發過程當中可使用其它數據結構或加鎖來規避此風險
  8. 【參考】 ThreadLocal 沒法解決共享對象的更新問題， ThreadLocal 對象建議使用 static修飾。
     這個變量是針對一個線程內全部操做共有的，因此設置爲靜態變量，全部此類實例共享此靜態變量 ，
     也就是說在類第一次被使用時裝載，只分配一塊存儲空間，全部此類的對象(只要是這個線程內定義的)均可以操控這個變量

• (七)控制語句

  1. 【強制】在一個 switch 塊內，每一個 case 要麼經過 break/return 等來終止，； 在一個 switch 塊內，都必須包含一個 default 語句而且放在最後，即便它什麼代碼也沒有。
  2. 【強制】在 if/else/for/while/do 語句中必須使用大括號。 即便只有一行代碼，避免使用單行的形式： if (condition) statements;
  3. 【推薦】 表達異常的分支時， 少用 if-else 方式;若是非得使用if-else 方式的話,爲避免後續代碼維護困難， 請勿超過 3 層 ;能夠改寫成衛語句，或者狀態模式來實現 if()… if()… if()…
  4. 【推薦】除經常使用方法（如 getXxx/isXxx）等外，不要在條件判斷中執行其它複雜的語句，將複雜邏輯判斷的結果賦值給一個有意義的布爾變量名，以提升可讀性。

• (八)註釋規約

  1. 【強制】類、類屬性、類方法的註釋必須使用 Javadoc 規範，使用/*內容/格式，不得使用//xxx 方式。
  2. 【強制】全部的類都必須添加建立者和建立日期。
  3. 【強制】全部的枚舉類型字段必需要有註釋，說明每一個數據項的用途。
  4. 【推薦】代碼修改的同時，註釋也要進行相應的修改，尤爲是參數、返回值、異常、核心邏輯等的修改。
     說明： 代碼與註釋更新不一樣步，就像路網與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後，就失去了導航的意義。
  5. 【參考】合理處理註釋掉的代碼。 在上方詳細說明，而不是簡單的註釋掉。 若是無用，則刪除。
     說明： 代碼被註釋掉有兩種可能性：
     1） 後續會恢復此段代碼邏輯。 (若是沒有備註信息，難以知曉註釋動機。)
     2） 永久不用。(建議直接刪掉（代碼倉庫保存了歷史代碼） 。)
  6. 【參考】對於註釋的要求：
     第1、可以準確反應設計思想和代碼邏輯；
     第2、可以描述業務含義，使別的程序員可以迅速瞭解到代碼背後的信息。
  7. 【參考】好的命名、代碼結構是自解釋的，註釋力求精簡準確、表達到位。避免出現註釋的一個極端：過多過濫的註釋，代碼的邏輯一旦修改，修改註釋是至關大的負擔。
  8. 【參考】特殊註釋標記，請註明標記人與標記時間。注意及時處理這些標記，經過標記掃描，常常清理此類標記。線上故障有時候就是來源於這些標記處的代碼。
     1） 待辦事宜（TODO） :（標記人，標記時間， [預計處理時間]）
     表示須要實現，但目前還未實現的功能。這其實是一個 Javadoc 的標籤，目前的 Javadoc尚未實現，但已經被普遍使用。只能應用於類，接口和方法（由於它是一個 Javadoc 標籤） 。
     2） 錯誤，不能工做（FIXME） :（標記人，標記時間， [預計處理時間]）
     在註釋中用 FIXME 標記某代碼是錯誤的，並且不能工做，須要及時糾正的狀況。
     (九)其它
  9. 【強制】後臺輸送給頁面的變量必須加 $!{var}——中間的感嘆號。 說明： 若是 var=null 或者不存在，那麼${var}會直接顯示在頁面上。
  10. 【強制】注意 Math.random() 這個方法返回是 double 類型，注意取值的範圍 0≤x<1（可以取到零值，注意除零異常） ，
      若是想獲取整數類型的隨機數，不要將 x 放大 10 的若干倍而後取整，
      直接使用 Random 對象的 nextInt 或者 nextLong 方法。
  11. 【強制】獲取當前毫秒數 System.currentTimeMillis(); 而不是 new Date().getTime();
      說明： 若是想獲取更加精確的納秒級時間值， 使用 System.nanoTime()的方式。在 JDK8 中，針對統計時間等場景，推薦使用 Instant 類。

2、異常日誌

• (一)異常處理

  3. 【強制】對大段代碼進行 try-catch，這是不負責任的表現。
     catch 時請分清穩定代碼和非穩定代碼，穩定代碼指的是不管如何不會出錯的代碼。
     對於非穩定代碼的 catch 儘量進行區分異常類型，再作對應的異常處理。
  4. 【強制】捕獲異常是爲了處理它，不要捕獲了卻什麼都不處理而拋棄之，
     若是不想處理它，請將該異常拋給它的調用者。
     最外層的業務使用者，必須處理異常，將其轉化爲用戶能夠理解的內容。
  5. 【強制】有 try 塊放到了事務代碼中， catch 異常後，若是須要回滾事務，必定要注意手動回滾事務。
  6. 【強制】 finally 塊必須對資源對象、流對象進行關閉，有異常也要作 try-catch。
     說明： 若是 JDK7 及以上，可使用 try-with-resources 方式。
  7. 【強制】不能在 finally 塊中使用 return， finally 塊中的 return 返回後方法結束執行，不會再執行 try 塊中的 return 語句。
  8. 【推薦】方法的返回值能夠爲 null，不強制返回空集合，或者空對象等，必須添加註釋充分說明什麼狀況下會返回 null 值。調用方須要進行 null 判斷防止 NPE 問題。
  9. 【推薦】防止 NPE，是程序員的基本修養，可使用 JDK8 的 Optional 類來防止 NPE 問題。
  10. 【推薦】定義時區分 unchecked / checked 異常，避免直接拋出 new RuntimeException()，
      更不容許拋出 Exception 或者 Throwable，應使用有業務含義的自定義異常。
      推薦業界已定義過的自定義異常，如： DAOException / ServiceException 等。
  11. 【參考】避免出現重複的代碼（Don’t Repeat Yourself） ，即 DRY 原則。
      說明： 隨意複製和粘貼代碼，必然會致使代碼的重複，在之後須要修改時，須要修改全部的副本，容易遺漏。必要時抽取共性方法，或者抽象公共類，甚至是共用模塊

• (二)日誌規約

  1. 【強制】應用中不可直接使用日誌系統（Log4j、 Logback） 中的 API，而應依賴使用日誌框架SLF4J 中的 API，使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式統一。
     import org.slf4j.Logger;
     import org.slf4j.LoggerFactory;
     private static final Logger logger = LoggerFactory.getLogger(Abc.class);
  2. 【強制】日誌文件推薦至少保存 15 天，由於有些異常具有以「周」爲頻次發生的特色。
  3. 【強制】應用中的擴展日誌（如打點、臨時監控、訪問日誌等） 命名方式：
     appName_logType_logName.log。 logType:日誌類型，推薦分類有stats/desc/monitor/visit 等； logName:日誌描述。這種命名的好處：經過文件名就可知道日誌文件屬於什麼應用，什麼類型，什麼目的，也有利於歸類查找。
     正例： mppserver 應用中單獨監控時區轉換異常，如：mppserver_monitor_timeZoneConvert.log
  4. 【強制】異常信息應該包括兩類信息：案發現場信息和異常堆棧信息。若是不處理，那麼經過關鍵字 throws 往上拋出。
     正例： logger.error(各種參數或者對象 toString + 「_」 + e.getMessage(), e);
  5. 【推薦】謹慎地記錄日誌。生產環境禁止輸出 debug 日誌； 有選擇地輸出 info 日誌； 若是使用 warn 來記錄剛上線時的業務行爲信息，必定要注意日誌輸出量的問題，避免把服務器磁盤撐爆，並記得及時刪除這些觀察日誌。
     說明： 大量地輸出無效日誌，不利於系統性能提高，也不利於快速定位錯誤點。 記錄日誌時請
     思考：這些日誌真的有人看嗎？看到這條日誌你能作什麼？能不能給問題排查帶來好處？

3、 MySQL 數據庫

• (一)建表規約

  1. 【強制】表達是與否概念的字段，必須使用 is_xxx 的方式命名，數據類型是 unsigned tinyint（1 表示是， 0 表示否） 。
     說明： 任何字段若是爲非負數，必須是 unsigned。
     正例： 表達邏輯刪除的字段名 is_deleted， 1 表示刪除， 0 表示未刪除。
  2. 【強制】表名、字段名必須使用小寫字母或數字， 禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，由於沒法進行預發佈，因此字段名稱須要慎重考慮。
     正例： getter_admin， task_config， level3_name
     反例： GetterAdmin， taskConfig， level_3_name
  3. 【強制】表名不使用複數名詞。
     說明： 表名應該僅僅表示表裏面的實體內容，不該該表示實體數量，對應於 DO 類名也是單數形式，符合表達習慣。
  4. 【強制】禁用保留字，如 desc、 range、 match、 delayed 等， 請參考 MySQL 官方保留字。
  5. 【強制】 主鍵索引名爲 pk_字段名； 惟一索引名爲 uk_字段名； 普通索引名則爲 idx_字段名。
     說明： pk_ 即 primary key； uk_ 即 unique key； idx_ 即 index 的簡稱。
  6. 【強制】小數類型爲 decimal，禁止使用 float 和 double。
     說明： float 和 double 在存儲的時候，存在精度損失的問題，極可能在值的比較時，獲得不正確的結果。若是存儲的數據範圍超過 decimal 的範圍，建議將數據拆成整數和小數分開存儲。
  7. 【強制】若是存儲的字符串長度幾乎相等，使用 char 定長字符串類型。
  8. 【強制】 varchar 是可變長字符串，不預先分配存儲空間，長度不要超過 5000，若是存儲長度大於此值，定義字段類型爲 text，獨立出來一張表，用主鍵來對應，避免影響其它字段索引效率。
  9. 【強制】表必備三字段： id, gmt_create, gmt_modified。
     說明： 其中 id 必爲主鍵，類型爲 unsigned bigint、單表時自增、步長爲 1。 gmt_create,gmt_modified 的類型均爲 date_time 類型。
  10. 【推薦】表的命名最好是加上「業務名稱_表的做用」。
      正例： tiger_task / tiger_reader / mpp_config
  11. 【推薦】庫名與應用名稱儘可能一致。
  12. 【推薦】若是修改字段含義或對字段表示的狀態追加時，須要及時更新字段註釋。
  13. 【推薦】字段容許適當冗餘，以提升查詢性能，但必須考慮數據一致。冗餘字段應遵循：
      1） 不是頻繁修改的字段。
      2） 不是 varchar 超長字段，更不能是 text 字段。
      正例： 商品類目名稱使用頻率高， 字段長度短，名稱基本一成不變， 可在相關聯的表中冗餘存儲類目名稱，避免關聯查詢。
  14. 【推薦】單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。
      說明： 若是預計三年後的數據量根本達不到這個級別，請不要在建立表時就分庫分表。
  15. 【參考】合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提高檢索速度。
      正例： 以下表，其中無符號值能夠避免誤存負數， 且擴大了表示範圍。
      對象 年齡區間 類型 表示範圍
      人 150 歲以內 unsigned tinyint 無符號值： 0 到 255
      龜 數百歲 unsigned smallint 無符號值： 0 到 65535
      恐龍化石 數千萬年 unsigned int 無符號值： 0 到約 42.9 億
      太陽 約 50 億年 unsigned bigint 無符號值： 0 到約 10 的 19 次方

• (二)索引規約

  1. 【強制】業務上具備惟一特性的字段，即便是多個字段的組合，也必須建成惟一索引。
     說明： 不要覺得惟一索引影響了 insert 速度，這個速度損耗能夠忽略，但提升查找速度是明顯的； 另外，即便在應用層作了很是完善的校驗控制，只要沒有惟一索引，根據墨菲定律，必然有髒數據產生。
  2. 【強制】 超過三個表禁止 join。須要 join 的字段，數據類型必須絕對一致； 多表關聯查詢時，保證被關聯的字段須要有索引。
     說明： 即便雙表 join 也要注意表索引、 SQL 性能。
  3. 【強制】在 varchar 字段上創建索引時，必須指定索引長度，不必對全字段創建索引，根據實際文本區分度決定索引長度便可。
     說明： 索引的長度與區分度是一對矛盾體，通常對字符串類型數據，長度爲 20 的索引，區分度會高達 90%以上，可使用 count(distinct left(列名, 索引長度))/count(*)的區分度來肯定。
  4. 【推薦】若是有 order by 的場景，請注意利用索引的有序性。 order by 最後的字段是組合索引的一部分，而且放在索引組合順序的最後，避免出現 file_sort 的狀況，影響查詢性能。
     正例： where a=? and b=? order by c; 索引： a_b_c
     反例： 索引中有範圍查找，那麼索引有序性沒法利用，如： WHERE a>10 ORDER BY b; 索引a_b 沒法排序。
  5. 【推薦】利用覆蓋索引來進行查詢操做， 避免回表。
     說明： 若是一本書須要知道第 11 章是什麼標題，會翻開第 11 章對應的那一頁嗎？目錄瀏覽一下就好，這個目錄就是起到覆蓋索引的做用。
     正例： 可以創建索引的種類：主鍵索引、惟一索引、普通索引，而覆蓋索引是一種查詢的一種效果，用 explain 的結果， extra 列會出現： using index。
  6. 【推薦】利用延遲關聯或者子查詢優化超多分頁場景。
     說明： MySQL 並非跳過 offset 行，而是取 offset+N 行，而後返回放棄前 offset 行，返回N 行，那當 offset 特別大的時候，效率就很是的低下，要麼控制返回的總頁數，要麼對超過特定閾值的頁數進行 SQL 改寫。
     正例： 先快速定位須要獲取的 id 段，而後再關聯：SELECT a.* FROM 表 1 a, (select id from 表 1 where 條件 LIMIT 100000,20 ) b where a.id=b.id
  7. 【推薦】 SQL 性能優化的目標：至少要達到 range 級別， 要求是 ref 級別， 若是能夠是 consts最好。
     說明：
     1） consts 單表中最多隻有一個匹配行（主鍵或者惟一索引） ，在優化階段便可讀取到數據。
     2） ref 指的是使用普通的索引（normal index） 。
     3） range 對索引進行範圍檢索。
     反例： explain 表的結果， type=index，索引物理文件全掃描，速度很是慢，這個 index 級別比較 range 還低，與全表掃描是小巫見大巫。
  8. 【推薦】建組合索引的時候，區分度最高的在最左邊。
     正例： 若是 where a=? and b=? ， a 列的幾乎接近於惟一值，那麼只須要單建 idx_a 索引便可。
     說明： 存在非等號和等號混合判斷條件時，在建索引時，請把等號條件的列前置。如： where a>?and b=? 那麼即便 a 的區分度更高，也必須把 b 放在索引的最前列。
  9. 【參考】建立索引時避免有以下極端誤解：
     1） 寧濫勿缺。 誤認爲一個查詢就須要建一個索引。
     2） 寧缺勿濫。 誤認爲索引會消耗空間、嚴重拖慢更新和新增速度。
     3） 抵制唯一索引。 誤認爲業務的唯一性一概須要在應用層經過「先查後插」方式解決。

• (三)SQL 語句

1. 【強制】不要使用 count(列名)或 count(常量)來替代 count()， count()是 SQL92 定義的標準統計行數的語法，跟數據庫無關，跟 NULL 和非 NULL 無關。
   說明： count(*)會統計值爲 NULL 的行，而 count(列名)不會統計此列爲 NULL 值的行。
   2. 【強制】 count(distinct col) 計算該列除 NULL 以外的不重複行數， 注意 count(distinctcol1, col2) 若是其中一列全爲 NULL，那麼即便另外一列有不一樣的值，也返回爲 0。
   3. 【強制】當某一列的值全是 NULL 時， count(col)的返回結果爲 0，但 sum(col)的返回結果爲NULL，所以使用 sum()時需注意 NPE 問題。
      正例： 可使用以下方式來避免 sum 的 NPE 問題： SELECT IF(ISNULL(SUM(g)),0,SUM(g))FROM table;
   4. 【強制】使用 ISNULL()來判斷是否爲 NULL 值。注意： NULL 與任何值的直接比較都爲 NULL。
      說明：
      1） NULL<>NULL 的返回結果是 NULL， 而不是 false。
      2） NULL=NULL 的返回結果是 NULL， 而不是 true。
      3） NULL<>1 的返回結果是 NULL，而不是 true。
   5. 【強制】 在代碼中寫分頁查詢邏輯時，若 count 爲 0 應直接返回，避免執行後面的分頁語句。
   6. 【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。
      說明： （概念解釋） 學生表中的 student_id 是主鍵，那麼成績表中的 student_id 則爲外鍵。若是更新學生表中的 student_id，同時觸發成績表中的 student_id 更新，則爲級聯更新。
      外鍵與級聯更新適用於單機低併發，不適合分佈式、高併發集羣；
      級聯更新是強阻塞，存在數據庫更新風暴的風險； 外鍵影響數據庫的插入速度。
   7. 【強制】禁止使用存儲過程，存儲過程難以調試和擴展，更沒有移植性。
   8. 【強制】數據訂正時，刪除和修改記錄時，要先 select，避免出現誤刪除，確認無誤才能執行更新語句。
   9. 【推薦】 in 操做能避免則避免，若實在避免不了，須要仔細評估 in 後邊的集合元素數量，控制在 1000 個以內。
   10. 【參考】 若是有全球化須要，全部的字符存儲與表示，均以 utf-8 編碼，注意字符統計函數的區別。
       說明：
       SELECT LENGTH(「輕鬆工做」)； 返回爲 12
       SELECT CHARACTER_LENGTH(「輕鬆工做」)； 返回爲 4
       若是要使用表情，那麼使用 utfmb4 來進行存儲，注意它與 utf-8 編碼的區別。
   11. 【參考】 TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日誌資源少，但 TRUNCATE無事務且不觸發 trigger，有可能形成事故，故不建議在開發代碼中使用此語句。
       說明： TRUNCATE TABLE 在功能上與不帶 WHERE 子句的 DELETE 語句相同。

• (四)ORM 映射

  1. 【強制】在表查詢中，一概不要使用 * 做爲查詢的字段列表，須要哪些字段必須明確寫明。
     說明： 1） 增長查詢分析器解析成本。 2） 增減字段容易與 resultMap 配置不一致。
  2. 【強制】 POJO 類的布爾屬性不能加 is，而數據庫字段必須加 is_，要求在 resultMap 中進行字段與屬性之間的映射。
     說明： 參見定義 POJO 類以及數據庫字段定義規定，在中增長映射，是必須的。
     在 MyBatis Generator 生成的代碼中，須要進行對應的修改。
  3. 【強制】sql.xml 配置參數使用： #{}， #param# 不要使用${} 此種方式容易出現 SQL 注入。
  4. 【強制】 iBATIS 自帶的 queryForList(String statementName,int start,int size)不推薦使用。
     說明：其實現方式是在數據庫取到 statementName對應的SQL語句的全部記錄，再經過 subList取 start,size 的子集合。
  5. 【強制】不容許直接拿 HashMap 與 Hashtable 做爲查詢結果集的輸出。
     說明： resultClass=」Hashtable」， 會置入字段名和屬性值，可是值的類型不可控。

4、工程結構

1. 【參考】分層領域模型規約：
    DO（Data Object） ：與數據庫表結構一一對應，經過 DAO 層向上傳輸數據源對象。
    DTO（Data Transfer Object） ：數據傳輸對象， Service 和 Manager 向外傳輸的對象。
    BO（Business Object） ：業務對象。 能夠由 Service 層輸出的封裝業務邏輯的對象。
    Query：數據查詢對象，各層接收上層的查詢請求。 注：超過 2 個參數的查詢封裝，禁止使用 Map 類來傳輸。
    VO（View Object） ：顯示層對象，一般是 Web 向模板渲染引擎層傳輸的對象。

5、安全規約

2. 【強制】用戶敏感數據禁止直接展現，必須對展現數據進行脫敏。 說明： 查看我的手機號碼會顯示成:158****9119，隱藏中間 4 位，防止隱私泄露。