1. 流程

數(shù)據(jù)庫表結(jié)構(gòu)的修改需要相關(guān)人員和Leader一起評(píng)審，保證符合涉及規(guī)范。

不允許使用root賬號(hào)，所有開發(fā)和測試應(yīng)當(dāng)分配指定賬號(hào)，并授予最小數(shù)據(jù)庫權(quán)限

2. 數(shù)據(jù)庫與表規(guī)范

表命名規(guī)范

1. 常規(guī)表表名以 t_開頭，t 代表 table 的意思，命名規(guī)則即 「t + 模塊（包含模塊含義的簡寫）+ 表（包含表含義的簡寫）」，比如用戶模塊的教育信息表：t_user_eduinfo。

2. 臨時(shí)表（RD、QA 或 DBA 同學(xué)用于數(shù)據(jù)臨時(shí)處理的表），命名規(guī)則：「temp 前綴+模塊+表+日期后綴」：temp_user_eduinfo_20210719

3. 備份表（用于保存和歸檔歷史數(shù)據(jù)或者作為災(zāi)備恢復(fù)的數(shù)據(jù)）命名規(guī)則，「bak 前綴+模塊+表+日期后綴」：bak_user_eduinfo_20210719

4. 區(qū)分位: iz_* [String(1)] 1表示是 0表示否，（禁用 is_,代碼生成實(shí)體有問題 )

5. 狀態(tài)位: *_status [String(1-2)] 狀態(tài)字段必須加注釋說明每個(gè)值代表含義

6. 同一個(gè)模塊的表盡可能使用相同的前綴，表名稱盡可能表達(dá)含義

7. 多個(gè)單詞以下劃線 _ 分隔

8. 常規(guī)表表名盡量不超過 30 個(gè)字符，temp 表和 bak 表視情況而定，也盡量簡短為宜，命名應(yīng)使用小寫

數(shù)據(jù)庫對(duì)象設(shè)計(jì)規(guī)范

1. 字符集統(tǒng)一使用utf8mb4,排序utf8mb4_general_ci

2. 不允許使用視圖、存儲(chǔ)過程、觸發(fā)器

3. 數(shù)據(jù)庫引擎統(tǒng)一innodb

4. 模塊劃分和代碼中業(yè)務(wù)模塊一致

表設(shè)計(jì)規(guī)范

1. 不要使用外鍵

2. 表必須有主鍵，設(shè)置為varchar(64)，唯一

3. 表必須有create_time(timestamp)字段

4. 表必須有update_time(timestamp)字段

5. 禁止使用復(fù)雜類型，json使用要看情況

6. 「需要json連接的字段，類型必須一致，防止隱式轉(zhuǎn)換」

7. 嚴(yán)禁使用分區(qū)表

8. 單表字段數(shù)不要太多，建議最多不要大于50個(gè)。過度的寬表對(duì)性能也是很大的影響。

9. MySQL在處理大表時(shí)，性能就開始明顯降低，所以建議單表物理大小限制在16GB，表中數(shù)據(jù)行數(shù)控制在2000W內(nèi)。^[業(yè)內(nèi)的規(guī)則是超過2000W性能開始明顯降低。但是這個(gè)值是靈活的，你可以根據(jù)實(shí)際情況進(jìn)行測試來判斷，比如阿里的標(biāo)準(zhǔn)就是500W，百度的確是2000W。實(shí)際上是否寬表，單行數(shù)據(jù)所占用的空間都有起到作用的。

] 10. 表字段注釋，每個(gè)字段必須設(shè)置注釋說明; 11. 表字段注釋，狀態(tài)類型的字段必須說明取值規(guī)則（比如性別sex取值規(guī)則）

3. 字段規(guī)范

字段命名規(guī)范

1. 字段命名需要表示其實(shí)際含義的英文單詞或簡寫，「單詞之間用下劃線 _ 進(jìn)行連接」，如 service_ip、service_port。

2. 「各表之間相同意義的字段必須同名」，比如 a 表和 b 表都有創(chuàng)建時(shí)間，應(yīng)該統(tǒng)一為 create_time，不一致會(huì)很混亂。

3. 多個(gè)單詞以下劃線 _ 分隔

4. 字段名盡量不超過 30 個(gè)字符，「命名應(yīng)該使用小寫」

字段設(shè)計(jì)規(guī)范

1. 「對(duì)于精確浮點(diǎn)型數(shù)據(jù)存儲(chǔ)，需要使用DECIMAL」，嚴(yán)禁使用FLOAT和DOUBLE

2. 禁止使用TEXT、BLOG字段，特殊情況除外

3. 「字段使用NOT NULL屬性」，可用默認(rèn)值代替NULL

4. 區(qū)分、狀態(tài)、類型字段，盡量用String類型，避免數(shù)字類型的一些問題

5. 字段默認(rèn)值（字段盡量不設(shè)置默認(rèn)值，采用編碼方式加默認(rèn)值）

6. 邏輯刪除字段，del_flag [int(1)]，1表示刪除 0表示未刪除 ，可選擇加

7. 樂觀鎖字段， update_count[Integer]，可選擇加

4. 索引規(guī)范

索引命名規(guī)范

1. 唯一索引使用「uni + 字段名」 來命名：create unique index uni_uid on t_user_basic(uid) 。

2. 非唯一索引使用「idx + 字段名」 來命名：create index idx_uname_mobile on t_user_basic(uname,mobile) 。

3. 多個(gè)單詞以「下劃線 _ 分隔」。

4. 索引名盡量不超過50個(gè)字符，命名應(yīng)該使用小寫，組合索引的字段不宜太多，不然也不利于查詢效率的提升。

5. 多單詞組成的列名，取盡可能代表意義的縮寫，如 test_contact表member_id和friend_id上的組合索引：idx_mid_fid。

6. 「理解組合索引最左前綴原則，避免重復(fù)建設(shè)索引」，如果建立了(a,b,c)，相當(dāng)于建立了(a), (a,b), (a,b,c)。

索引設(shè)計(jì)規(guī)范

1. 索引必須創(chuàng)建在索引選擇性（區(qū)分度）較高的列上，選擇性的計(jì)算方式為: ?selecttivity = count(distinct c_name)/count(*) ; 如果區(qū)分度結(jié)果小于0.2，則不建議在此列上創(chuàng)建索引，否則大概率會(huì)拖慢SQL執(zhí)行

2. 單張表的索引數(shù)量理論上應(yīng)「控制在5個(gè)以內(nèi)」。經(jīng)常有大批量插入、更新操作表，應(yīng)盡量少建索引，索引建立的原則理論上是「多讀少寫的場景」。

3. 「ORDER BY，GROUP BY，DISTINCT的字段需要添加在索引的后面，形成覆蓋索引」

4. 聯(lián)合索引注意「最左匹配原則」：必須按照從左到右的順序匹配，MySQL會(huì)一直向右匹配索引直到遇到范圍查詢(>、<、between、like)然后停止匹配。如：depno=1 and empname>'' and job=1 如果建立(depno,empname,job)順序的索引，job是用不到索引的。

5. 應(yīng)需而取策略，查詢記錄的時(shí)候，「不要一上來就使用」*，只取需要的數(shù)據(jù)，可能的話盡量只利用索引覆蓋，可以減少回表操作，提升效率。

6. 避免索引失效的原則：「禁止對(duì)索引字段使用函數(shù)、運(yùn)算符操作，會(huì)使索引失效」。

7. 「避免非必要的類型轉(zhuǎn)換」，字符串字段使用數(shù)值進(jìn)行比較的時(shí)候會(huì)導(dǎo)致索引無效。

8. 「模糊查詢'%value%'會(huì)使索引無效」，變?yōu)槿頀呙瑁驗(yàn)闊o法判斷掃描的區(qū)間，「但是'value%'是可以有效利用索引」。

9. 「索引覆蓋排序字段」，這樣可以減少排序步驟，提升查詢效率

10. 「盡量的擴(kuò)展索引，非必要不新建索引」。比如表中已經(jīng)有a的索引，現(xiàn)在要加(a,b)的索引，那么只需要修改原來的索引即可。

擴(kuò)展下最左前綴

這里創(chuàng)建一個(gè)索引

CREATE?INDEX?idx_name?ON?users?(first_name,?last_name);


在這個(gè)索引中，first_name 是最左前綴?，F(xiàn)在，當(dāng)您執(zhí)行類似以下的查詢時(shí)，索引可以被有效地利用：

SELECT?*?FROM?users?WHERE?first_name?=?'John'?AND?last_name?=?'Doe';


5. SQL 查詢編寫規(guī)范

1. 不允許使用select *

2. 查詢必須加where條件，避免全表掃描

3. 如果必須有TEXT對(duì)象，必須單獨(dú)加表并關(guān)聯(lián)

4. where條件中過濾字段嚴(yán)禁使用任何函數(shù)，包括數(shù)據(jù)類型轉(zhuǎn)換函數(shù)

5. 分頁查詢必須帶排序條件

6. 用in/union替換or，并注意in個(gè)數(shù)小于300

7. 如無必要不要使用%前綴進(jìn)行模糊查詢，避免全表查詢

8. 避免使用子查詢，轉(zhuǎn)為join連接

子查詢性能差原因

「「·」」?子查詢的結(jié)果集無法使用索引，通常子查詢的結(jié)果集會(huì)被存儲(chǔ)到臨時(shí)表中，不論是內(nèi)存臨時(shí)表還是磁盤臨時(shí)表都不會(huì)存在索引，所以查詢性能 會(huì)受到一定的影響；

「「·」」?特別是對(duì)于返回結(jié)果集比較大的子查詢，其對(duì)查詢性能的影響也就越大；

「「·」」?由于子查詢會(huì)產(chǎn)生大量的臨時(shí)表也沒有索引，所以會(huì)消耗過多的CPU和IO資源，產(chǎn)生大量的慢查詢。

6. 事務(wù)管理和性能優(yōu)化

1. 所有方法涉及到更新、刪除、添加操作需要使用@Transactional注解

2. 數(shù)據(jù)量大的情況下， 需要分批次操作

7. 安全性考慮

• 數(shù)據(jù)庫配置應(yīng)當(dāng)使用druid等框架對(duì)明文進(jìn)行加密

• 避免拼接SQL

• 防止SQL注入