C# 編碼規範

本文是參考阿里的Java編碼規範修改的C#版本，自整理並編寫，歡迎指正！ 

1. 編程規約

（一）命名規約

1.【強制】代碼中當且僅當私有成員可使用下劃線開始

反例：public string _name

2.【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不能容許直接使用中文的方式。

說明：正確的英文拼寫和語法，可讓讀者易於理解，避免歧義。注意，即便純拼音命名方式也要避免採用。

反例：IsPiLiang [是否批量操做] / Kase [卡色] / numLing [領用數量]

3.【強制】類名、類的屬性、方法名、命名空間使用UpperCamelCase大寫駝峯 風格，英文單詞首字母大寫，必須聽從駝峯形式，但如下情形例外（領域模型的相關明明）CEO / DBO 等。

正例：SysuserController / ItemInfo / TcpHelper / GetInfo()

反例：sysuserController / Iteminfo / TCPHelper / getInfo()

4.【強制】參數名、成員變量、局部變量都統一使用lowerCamelCase 小駝峯風格，除首單詞外其餘單詞首字母大寫，必須聽從駝峯形式。

正例：localCache / userList

5.【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語意表達完整清楚，不要嫌名字長。

正例：MAX_STOCK_COUNT

反例：MAX_COUNT

6.【強制】抽象類命名使用 Abstract或Base開頭；異常類命名使用Exception結尾；測試類命名以它要測試的類名稱開始，以Test結尾。

7.【強制】杜絕徹底不規範的縮寫，避免望文不知義。

反例：AbstractClass 「 縮寫 」 命名成AbsClass，condition 「 縮寫 」 成condi，此類隨意縮寫嚴重下降了代碼的可閱讀性。

8.【推薦】若是使用了設計模式，建議在類名中體現出具體模式。

說明：將設計模式體如今名字中，有利於閱讀者快速理解架構設計思想。

正例：public class SysuserController

  Public class OrderFactory

  Public class TcpProxy

9.【推薦】類中的聲明、方法和屬性加上有效的Summery註釋。

正例：

/// <summary>

/// 該類是用於對用戶的控制器操做類

/// </summary>

public class SysuserController

{

　　/// <summary>

　　/// 用戶名

　　/// </summary>

　　public string name;

　　/// <summary>

　　/// 得到用戶名

　　/// </summary>

　　Public string getName()

　　{

　　　　// return this.name;

　　}

}

10.【參考】枚舉類名建議帶上E前綴或Enum後綴，枚舉成員名稱須要全大寫，單詞間用下滑線隔開。

說明：枚舉其實就是特殊的常量類i，切構造方法被默認強制是私有。

正例：枚舉名字：EState / DealStatusEnum，成員名：SUCCESS / UNKOWN_REASON

（二）常量定義

1.【強制】不容許出現任何魔幻值（即未經定義的常量）直接出如今代碼中。

反例：string key = 「 cacheKey_ 」 + user.Name;

正例：string keyPrefix = 「 cacheKey_ 」 ;

  　　string key = keyPrefix + user.Name;

2.【推薦】不要使用一個常量類，來維護全部的常量，應該按常量的功能進行歸類，分開維護，或交由具體的業務類中定義常量。如：緩存相關的常量放在類：CacheConstant中。系統配置相關的常量放在類：SysConfigConstant中。

說明：大而全的常量類，非得使用查找功能才能定位到修改的常量，不利於理解和維護。

（三）格式規約

1.【強制】大括號的使用約定。若是大括號內爲空，則簡介的寫成 { } 便可，不須要換行；若是是非空代碼塊，則左括號和右括號各佔一行，內容塊另起一行。

正例：

public string getName() { }

public string getName()

{

　　return this.Name;

}

反例：

public string getName() {

　　return this.Name;

}

2.【強制】if / for / while / switch / do 等保留字與左右括號之間都必須加空格。

3.【強制】任何運算符左右必須加一個空格。

說明：運算符包括賦值運算符 = 、邏輯運算符&&、加減乘除符號、三目運算符等。

4.【強制】縮進採用4個空格，儘可能不要使用tab字符。

說明：根據vs設定，tab默認已經是4個空格，不須要作變更。

正例：

public static void main(string[] args)

{

    　// 縮進4個空格

　　string name = 「 Jack 」 ;

　　// 運算符的全部必須空一格

　　bool isMe = true;

　　// 關鍵字if與括號之間必須有一格空格，括號內的方法體不須要空格

　　if (isMe == true)

　　{

　　　　Console.WriteLine( 「 my name is 」 + name);

　　}

　　else

　　{

　　　　Console.WriteLine( 「 your name is 」 + name);

　　}

}

5.【推薦】單行字符數限制不超過120個，超出徐換行，換行時遵照以下原則：

1）第二行相對第一行縮進4個空格，從第三行開始再也不繼續縮進，參考示例。

2）運算符與下文一塊兒換行。

3）方法調用的點符號與下文一塊兒。

4）在多個參數超長，都好後進行換行。

5）在括號前不要換行，見反例。

正例：

　　// 超過120個字符的狀況下，換行縮進4個空格，而且方法錢的點符號一塊兒換行

　　var host = new WebHostBuilder()

　　　　　　　　.UseKestrel()

　　　　　　　　.UseContentRoot(Directory.GetCurrentDirectory())

　　　　　　　　.UseIISIntegration()

　　　　　　　　.UseStartup<Startup>()

　　　　　　　　.UseApplicationInsights()

　　　　　　　　.Build();

反例：

　　// 超過120個字符，不要再括號前換行

　　var host = new WebHostBuilder()

　　　　　　　　.UseKestrel()

　　　　　　　　.UseContentRoot(Directory.GetCurrentDirectory())

　　　　　　　　.UseIISIntegration()

　　　　　　　　.UseStartup<Startup>

　　　　　　　　().UseApplicationInsights()

　　　　　　　　.Build();

　　// 參數不少的方法調用可能超多120個字符，不要在逗號錢換行

　　Method(args1, args2, args3 , args4);

6.【強制】方法參數在定義和傳入時，多個參數逗號後必須加空格。

正例：下例中實參的 」 a 」 ，後邊必需要有一個空格。

　　Method( 「 a 」 ,  「 b 」 ,  「 c 」 );

7.【推薦】沒有必要增長若干空格來使某一行相應的字符對其。

正例：

　　int a = 3;

　　long b = 4;
　　string str = 「 hello world 」 ;

說明：增長str這個變量，若是對其，則給a、b都要增長几個空格，在變量比較多的狀況下，是一種累贅的事情。

（四）OOP面向對象規約

1.【強制】避免經過一個類的對象引用訪問此類的靜態變量或靜態方法，無謂增長編譯器解析成本，直接用類名來訪問便可。

2.【強制】相同的參數類型，相同的業務含義，纔可使用可變參數，避免使用Object

說明：可變參數必須放置在參數列表的最後。

正例：public void sendMessage (string msgContent, params string[] userList)

3.【強制】不能使用過期的類或方法（[Obsolate]標識）

說明：C#中對於標記過期的方法，有可能會在新版本的.Net Framework中剔除，所以不建議繼續使用此類或方法。

4.【強制】Object 的Equals方法容易拋空引用異常，應使用常量或肯定有值得對象來調用Equals。

正例： 」 Jack 」 .Equals(user);

反例：user.Equals( 「 Jack 」 );

5.【強制】構造方法中禁止加入業務邏輯，若有初始化邏輯等，請放在Init() 方法中。

7.【強制】幫助類或業務接口類，應該使用靜態方法定義接口，使用類名.方法名直接調用，避免對象聲明。

正例：Helper.ToString();

反例：Helper.Instance.ToString();

7.【推薦】當一個類有多個構造方法，或多個同名方法，這些方法應該按照順序放置在一塊兒，便於閱讀。

8.【推薦】類內方法定義順序依次是：常量、字段、屬性、方法，按照public -> protected -> private 排序。

說明：共有方法是類的調用者和維護者最關心的方法，首屏展現最好；保護方法雖然只是子類關心，也多是 「 模板設計模式 」 下的和新方法；二私有方法通常不須要特別關心，是一個黑盒實現，所以方法信息價值較低。

9.【推薦】循環體內，字符串的拼接方式，使用StringBulder的Append或AppendFormat方法進行擴展。

反例：

　　string str = 「 start 」 ;

　　for (int i = 0; i < 100; i++)

　　{

　　　　str = str + 「 hello 」 ;

　　}

說明：反編譯出的字節碼文件顯示，每次循環都會new出一個StringBuilder對象，而後進行Append操做，最後經過ToString方法返回string對象，形成內存資源浪費。

10.【推薦】類成員與方法訪問控制從嚴：

1）若是不容許外部直接經過new來建立對象，那麼構造方法必須是private。

2）工具類不容許有public或default構造方法。

3）類非static成員變量而且與子類共享，必須是protected。

4）類非static成員變量而且僅在本類使用，必須是private。

5）類static成員變量若是僅在本類使用，必須是private。

6）類成員方法只供內部調用，必須是private。

7）類成員方法只對繼承類公開，那麼限制爲protected。

說明：任何類、方法、參數、變量，嚴控訪問範圍，過寬泛的訪問範圍，不利於模塊解耦。思考：若是一個private的方法，想刪除就刪除，但是一個public的Service方法，或者一個public的成員變量，刪除一下，不得手心冒汗嗎？變量像本身的小孩，儘可能在本身的時限內，變量做用域太大，若是無限制的處處跑，那麼你會擔憂的。

（五）控制語句

1.【強制】在一個switch塊內，每一個case要麼經過break/return等來終止，要麼註釋說明程序將繼續執行到哪個case爲止：在一個switch塊內，都必須包含一個default語句，而且放在最後，即便它什麼代碼都沒有。

2.【強制】在 if / else / for / while / do 語句中都必須使用大括號，即便只有一行代碼，避免使用下面的形式： if (condition) do something...

3.【推薦】儘可能少使用else，if-else的方式能夠改寫爲：

　　if (condition)

　　{

　　　　... Do something;

　　　　return obj;

　　}

4.【推薦】除經常使用方法（如GetXXX / IsXXX）外，不要再條件判斷中執行其餘複雜的語句，將複雜邏輯判斷的結果賦值給一個有意義的bool變量，以提升可讀性。

說明：不少id語句內的邏輯香坊複雜，閱讀者須要分析條件表達式的最終結果，才能明確什麼樣的條件執行什麼樣的語句，那麼若是閱讀者分析邏輯表達式錯誤呢？

正例：

　　// 僞代碼以下：

　　bool exsisted = file.Exsist() && obj != null && ...;

　　If (exsisted)

　　{

　　　　...

　　}

反例：

　　if (file.Exsist() && obj != null && ...)

5.【推薦】循環體內的語句要考慮性能，如下操做盡可能移至循環體外處理，如定義對象、變量、獲取數據庫鏈接，進行沒必要要的 try-catch操做（這個try-catch是否能夠移至循環體外）。

6.【參考】方法中須要進行參數校驗的場景：

1）調用頻次低的方法。

2）執行時間開銷很大的方法，參數教研室間幾乎能夠忽略不計，但若是由於參數錯誤致使中間執行回退，或者錯誤，那麼得不償失。

3）須要極高穩定性和可用性的方法。

4）對外提供的開放接口，無論是Api仍是Http接口。

5）敏感權限入口。

7.【參考】方法中不須要參數校驗的場景：

1）極有可能唄循環調用的方法，不建議對參數進行校驗。但在方法說明裏必須註明外部參數檢查要求低。

2）底層的方法調用頻度都比較高，通常不校驗。畢竟是像純淨水過濾的最後一道，參數錯誤不太可能到底層纔會暴露問題。

3）被聲明成private只會被本身代碼所調用的方法，若是可以肯定調用方法的代碼傳入參數已經作過交叉或確定不會有問題，此時能夠不作校驗參數。

（六）註釋規約

1.【強制】類、雷屬性、類方法的註釋必須使用C# Summary 規範，使用：

　　/// <summary>

　　/// ....

　　/// </summary>

格式，不得使用 //... 方式。

說明：在vs中，Summary方式會提示相關的註釋，生成Summary能夠正確輸出相應的註釋。工程調用方法是，不進入方法，便可懸浮提示方法、參數、返回值的意義，提升閱讀效率。

2.【強制】全部的抽象方法（包括接口中的方法）必須使用Summary註釋，除了返回值、參數、異常說明外，還必須指出該方法作了什麼事，實現了什麼功能。

說明：對於子類的實現要求，或者調用注意事項，請一併說明。

3.【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用 // 註釋。方法內部多行註釋使用 /*  */註釋，注意與代碼對齊。

4.【推薦】語氣 「 半吊子 」 英文來註釋，不如用中文註釋把問題說清楚。但專有名字與關鍵字保持英文原文便可。

反例： 「 TCP鏈接超時 」 解釋成 「 傳輸控制協議鏈接超時 」 ，理解反而費腦筋。

5.【推薦】代碼修改的同事，註釋也要進行相應的修改，預期是參數、返回值、異常、核心邏輯等的修改。

說明：代碼與註釋更新不一樣步，就像網路與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後，就失去了導航的意義。

6.【參考】註釋掉的代碼儘量而配合說明，而不是簡單的註釋掉。

說明：代碼被註釋掉有兩種可能性：1）後續會恢復此段代碼邏輯。2）永久不用。前者若是沒有備註信息，難以知曉註釋動機。後者建議直接刪掉（代碼倉庫保存了歷史代碼）。

7.【參考】對於註釋的要求：第1、可以準確反應設計思想和代碼邏輯；第2、可以描述業務含義，使別的程序員可以迅速瞭解到代碼背後的信息，徹底沒有註釋的大段代碼，對於閱讀者形同天書，註釋是給本身看的，即便隔很長時間，也可以清晰理解當時的思路；註釋也是給繼任者看的，使其可以快讀接替本身的工做。

8.【參考】好的命名、代碼結構是自解釋的，註釋力求精簡準確，表達到位。避免出現註釋的一個極端：過多濫的註釋，代碼邏輯一旦修改，修改註釋是至關大的負擔。

反例：

　　// put elephant into fridge

　　Put(elephant, fridge);

方法名put，加上兩個有意義的變量名 elephant和fridge，已經說明了這是在幹什麼，語義清晰的代碼不須要額外的註釋。

9.【參考】特殊註釋標記，請註明標記人與標記時間。注意及時處理這些標記，經過標記掃描，常常清理此類標記。線上故障有時候就是來源於這些標記處的代碼。

1）待辦事宜（TODO）：（標記人、標記時間，[預計處理時間]）表示須要實現，但目前還未實現的功能。

（七）接口規約

1.【強制】業務接口的返回格式爲：

{

    "code": 0,

    "message": "這裏是返回信息",

    "data": {}

}

code 標識接口返回的狀態碼，message 標識接口返回的信息，data 標識接口返回的數據。此三個單詞均使用小寫。

2.【強制】返回值code，0標識失敗，1標識成功

說明：大多數系統都使用code做爲接口調用成功與否的判斷標誌，但對於code沒有統一的規範，現對於新系統發起約束，0爲失敗，1爲成功。

2. 異常日誌

（一）異常處理

1.【強制】異常不要用來作流程控制，條件控制。由於異常的處理效率比條件分支低。

2.【強制】對大段代碼進行try-catch，這是不負責任的表現。catch時請分清穩定代碼合肥穩定代碼，穩定代碼指的是不管如何都不會出錯的代碼。對於費穩定代碼的catch儘可能可能的進行區分異常類型，再作對應的異常處理。

3.【強制】捕獲異常是爲了處理它，不要捕獲了卻什麼都不處理而拋棄之，若是不想處理它，就將該異常拋給他的調用者。最外層的業務使用者，必須處理異常，將其轉化爲用戶能夠理解的內容。

4.【強制】有try塊放到了事務代碼中，catch異常後，若是要回滾事務，必定要注意手動回滾事務。

5.【強制】finally塊必須對資源對象、流對象進行關閉，有異常也要作tyr-catch。

6.【強制】捕獲異常與拋異常，必須是徹底匹配，或者捕獲異常是拋異常的父類。

說明：若是預期對方拋的是繡球，實際接到的是鉛球，就會產生意外狀況。

7.【推薦】方法的返回值能夠是null，不強制返回空集合或空對象等，必須添加註釋充分說明什麼狀況下會返回null值。調用方進行null判斷，防止NRE空引用異常問題（NullReferenceException）。

8.【推薦】防止NRE，是程序員的基本修養，注意NRE產生的場景：

1）返回類型爲包裝數據類型，有多是null，返回?類型時注意判空。

2）數據庫的查詢結果可能爲null。

3）集合多是非空的，但集合裏的元素有多是null。

4）級聯調用 obj.GetA().GetB().GetC()，一連串調用，容易產生NRE。

9.【推薦】在代碼中使用 「 拋異常 」 仍是 「 返回錯誤碼 」 ，對於公司外的http/api開放接口，必須使用 「 錯誤碼 」 ，而應用內部推薦異常拋出；跨應用間的調用，推薦使用統一的返回格式和狀態碼規範。

10.【參考】避免出現重複的代碼

說明：隨意複製和黏貼代碼，必然會致使代碼的重複，在之後須要修改時，須要修改全部的副本，容易遺漏。必要時，抽取公共方法，或者抽象公共類，甚至是公用模塊。

（二）日誌規約

3. MySQL規約

（一）建表規約

1.【強制】表達是否概念的字段，必須使用is_xxx的方式命名，數據類型是bit

說明：人和字段若是爲非負數，必須是unsigned。

2.【強制】表名、字符案名必須是用小寫字母或數字，禁止出現數字開頭、兩個下劃線中間值出現數字。數據庫字段名的修改代價很大，由於沒法進行預發佈，因此字段名稱須要慎重考慮。

3.【強制】表名不適用複數名詞。

說明：表名應該僅僅表示表裏的內容實體，不該該表示實體數量，對應於DBO類名也是單數形式，符合表達習慣。

4.【強制】禁用保留字，如desc、range、match等，請參考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，create_time，update_time。

說明：其中id比爲主鍵，類型爲 unsigned bigint，單表時自增、步長爲1。create_time、update_time類型均爲datetime類型。

10.【推薦】若是修改字段含義或對字段標識的狀態追加時，須要及時更新字段註釋。

11.【推薦】字段容許適當的冗餘，以提升性能，可是必須考慮數據同步的狀況。冗餘字段應遵循：

1）不是頻繁修改的字段。

2）不是varchar超長字段，更不能是text字段。

正例：商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗餘存儲類目名稱，避免關聯查詢。

12.【推薦】單錶行數超過500萬行或者單表容量超過2GB，才進行分庫分表。

說明：若是預計三年後的數據量根本達不到這個級別，請不要再建立表時就分庫分表。

13.【參考】合適的字符存儲長度，不但節約數據庫表空間、借閱索引存儲，更重要的是提高檢索速度。

正例：無符號值能夠避免誤存負數，且擴大了表示範圍。

（二）索引規約

1.【強制】業務上具備惟一特性的字段，即便是組合字段，也必須建成惟一索引。

說明：不要覺得惟一索引印象了insert速度，這個速度損耗能夠忽略，但提升查找速度是明顯的。另外，即便在應用層作了很是完善的校驗控制，只要沒有惟一索引，根據墨菲定律，必而後髒數據產生。

2.【強制】超過三個表禁止join。須要join的字段，數據類型必須絕對一致；多表關聯查詢時，保證被關聯的字段須要有索引。

說明：即便雙表join，也要注意表索引、SQL性能。

3.【強制】在varchar字段上建索引時，必須指定索引長度，不必對全字段創建索引。根據實際文本區分度決定索引長度便可。

說明：索引償付與區分度是一對矛盾體。通常對字符串類型數據，長度爲20的索引，，區分度或達到90%以上。可使用count（distinct left（列名，索引長度））/count（*）的區分度來肯定。

4.【強制】頁面搜索嚴禁左模糊或全模糊，若是須要請走搜索引擎來解決。

說明：索引文件具備B-Tree的最左前綴匹配特性，若是左邊的值來肯定，那麼沒法使用此索引。

5.【推薦】若是有order by的場景，請注意利用索引的有序性。order by最後的字段是組合索引的一部分，而且放在索引組合順序的最後，避免出現file_sort的狀況，影響查詢性能。

正例：where a = XXX and b = YYY order by c; 索引：a_b_c

反例：索引中有範圍的查找，那麼索引有序性沒法利用，如：WHERE a > 10 order by b;索引 a_b 沒法排序。

6.【推薦】利用覆蓋索引來進行查詢操做，避免回表。

說明：若是一本書知道第11章是什麼標題，會翻開第11章對應的那一頁嗎？目錄瀏覽一下就好，這個目錄就是起到覆蓋索引的所用。

正例：可以創建索引的種類：主鍵索引、惟一索引、普通索引，二覆蓋索引是一種查詢的一種效果，用explain的結果，extra列會出現using index。

7.【推薦】利用延遲關聯或者子查詢優化多分頁場景。

說明：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

8.【推薦】SQL 性能優化的目標：至少要達到 range 級別，要求是 ref 級別，若是能夠是 consts 最好。

說明：

1）consts 單表中最多隻有一個匹配行（主鍵或者惟一索引），在優化階段便可讀取到數據。

2）ref 指的是使用普通的索引（normal index）。

3）range 對索引進行範圍檢索。 反例：explain 表的結果，type=index，索引物理文件全掃描，速度很是慢，這個 index 級 別比較 range 還低，與全表掃描是小巫見大巫。

9.【推薦】建組合索引的時候，區分度最高的在最左邊。

正例：若是 where a= ? and b= ? ，a 列的幾乎接近於惟一值，那麼只須要單建 idx_a 索引便可。

說明：存在非等號和等號混合判斷條件時，在建索引時，請把等號條件的列前置。如：where a > XXX and b = YYY 那麼即便a的區分度更高，也必須把 b放在索引的最前列。

10.【參考】建立索引時避免有以下極端誤解：

1）誤認爲一個查詢就須要建一個索引。

2）誤認爲索引會消耗空間、嚴重拖慢更新和新增速度。

3）誤認爲惟一索引一概須要在應用層經過 「 先查後插 」 方式解決。

（三）SQL規約

1.【強制】不要使用count(列名)或count(常量)來替代count(*)，count(*)是SQL92 定義的 標準統計行數的語法，跟數據庫無關，跟 NULL 和非 NULL 無關。

說明：count(*)會統計值爲NULL的行，而count(列名)不會統計此列爲NULL值的行。

2.【強制】count(distinct col) 計算該列除 NULL 以外的不重複行數，注意count(distinct col1, col2)若是其中一列全爲NULL，那麼即便另外一列有不一樣的值，也返回爲 0。

3.【強制】當某一列的值全是NULL時，count(col)的返回結果爲0，但sum(col)的返回結果爲 NULL，所以使用 sum()時需注意NRE問題。

正例：可使用以下方式來避免sum的NRE問題：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("輕鬆工做")；返回爲 

若是要使用表情，那麼使用utfmb4來進行存儲，注意它與utf-8編碼的區別。

11.【參考】TRUNCATE TABLE比DELETE速度快，且使用的系統和事務日誌資源少，但TRUNCATE無事務且不觸發trigger，有可能形成事故，故不建議在開發代碼中使用此語句。

說明：TRUNCATE TABLE在功能上與不帶 WHERE子句的DELETE語句相同。

（四）ORM（對象關係映射）規約

1.【強制】在表查詢中，一概不要使用 * 做爲查詢的字段列表，須要哪些字段必須明確寫明。

說明：1）增長查詢分析器解析成本。2）增減字段容易與 resultMap 配置不一致。

2.【強制】xml 配置中參數注意：#{}，#param# 不要使用${} 此種方式容易出現 SQL 注入。

3.【強制】更新數據表記錄時，必須同時更新記錄對應的 update_time 字段值爲當前時間。

4.【推薦】不要寫一個大而全的數據更新接口，無論是否是本身的目標更新字段，都進行update這是不對的。執行 SQL 時，儘可能不要更新無改動的字段，一是易出錯；二是效率低；