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.【強制】表名不使復數名詞。
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的範圍，建議將數據拆成整數和小數分開存儲。
8.【強制】如果存儲的字符串長度幾乎相等，使用char定長字符串類型。
9.【強制】表必備三字段：id，create_time，update_time,且類型均為datetime類型
10.【推薦】表的名稱最好是加上“業務名稱_表的作用”。
11.【推薦】庫名與應用名稱盡量保持一致。
12.【推薦】如果修改字段含義或對字段表示的狀態追加時，需要及時更新字段註釋。
13.【推薦】字段允許適當冗余，以提高查詢性能，但必須考慮數據一致。冗余字段應遵循：
2）不是varchar超長字段，更不能是text字段。
正例：商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗余存儲類目名稱，避免關聯查詢。
14.【推薦】單表行數超過500萬行或者單表容量超過2GB，才推薦進行分庫分表。
說明：如果預計三年後的數據量根本達不到這個級別，請不要在創建表時就分庫分表。
15.【參考】合適的存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提升檢索速度。
二.索引規約
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=? and b=? 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>? and b=? 那麽及時a的區分度更高，也必須把b放在索引的最前列。
10.【推薦】防止因為字段類型不同造成的隱式轉換，導致索引失效。
11.【參考】創建索引避免有如下極端誤解：
1）寧濫勿缺。誤認為一個查詢就需要建一個索引。
2）寧缺勿濫。誤認為索引會消耗空間、嚴重拖慢更新和新增速度。
3）抵制唯一索引。誤認為業務的唯一性一律需要在應用層通過“先查後插”方式能解決。
三.SQL語句
1.【強制】不要使用count(列名)或count(常量)來替代count(),count()是SQL92定義的
標準統計行數的語法，跟數據庫無關，跟NULL和非NULL無關。
說明：count(*)會統計值為NULL的行，而count(列名)不會統計此列值為NULL值的行。
2.【強制】count(distinct col)計算該列除NULL之外的不重復行數，註意count(distict
col1,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語句相同。
MySQL數據庫使用規範