本文是參考阿里的Java編碼規范修改的C#版本，自整理並編寫，歡迎指正！
-
編程規約
（一）命名規約
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 ” ;
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.【參考】對於注釋的要求：第一、能夠准確反應設計思想和代碼邏輯；第二、能夠描述業務含義，使別的程序員能夠迅速了解到代碼背后的信息，完全沒有注釋的大段代碼，對於閱讀者形同天書，注釋是給自己看的，即使隔很長時間，也能夠清晰理解當時的思路；注釋也是給繼任者看的，使其能夠快讀接替自己的工作。
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為成功。
-
異常日志
（一）異常處理
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.【參考】避免出現重復的代碼
說明：隨意復制和黏貼代碼，必然會導致代碼的重復，在以后需要修改時，需要修改所有的副本，容易遺漏。必要時，抽取公共方法，或者抽象公共類，甚至是公用模塊。
（二）日志規約
-
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 時，盡量不要更新無改動的字段，一是易出錯；二是效率低；