最詳細的MySQ設計與開發規格【推薦收藏】

以下這篇文章為大家整理最詳細的MySQL 設計與開發規範，希望對大家有幫助。

                                                       

資料庫物件命名規範

資料庫物件

資料庫物件是資料庫的組成部分，常見的有以下幾種：表（Table ）、索引（Index）、檢視（View）、圖表（Diagram）、缺省值（Default）、規則（Rule）、觸發器（Trigger）、預存程序（Stored Procedure）、 使用者（User）等。命名規範是指資料庫物件如資料庫（SCHEMA）、表（TABLE）、索引（INDEX）、約束（CONSTRAINTS）等的命名約定。 【推薦：mysql影片教學】

資料庫物件全域命名規格

1、命名使用有意義的英文詞彙，詞彙中間以下劃線分隔

2、命名只能使用英文字母、數字、底線，以英文字母開頭

#3、避免用MySQL的保留字如：backup、call、group等

4、所有資料庫物件使用小寫字母，實際上MySQL中是可以設定大小寫是否敏感的，為了確保統一性，我們這邊規範全部小寫表示。

資料庫命名規格

1、資料庫命名盡量不超過30個字元。

2、資料庫命名一般為專案名稱 代表函式庫意義的簡寫，例如IM專案的工作流程資料庫，可以是 im_flow。

3、資料庫建立時必須新增預設字元集和校對規則子句。預設字元集為UTF8（已遷移dumbo的使用utf8mb4）

4、命名應使用小寫。

表命名規範

1、常規表表名以t_開頭，t代表table的意思，命名規則即t 模組（包含模組意義的簡寫）表（包含表格意義的簡寫），例如使用者模組的教育資訊表：t_user_eduinfo。

2、臨時表（RD、QA或DBA同學用於資料暫存處理的表格），命名規則：temp前綴模組表日期後綴：temp_user_eduinfo_20210719

#3 、備份表（用於保存和歸檔歷史資料或作為災備恢復的資料）命名規則，bak前綴模組表日期後綴：bak_user_eduinfo_20210719

4、同一個模組的表盡可能使用相同的前綴，表名稱盡可能表達含義

5、多個單字以下劃線_ 分隔

6、常規表表名盡量不超過30個字符，temp表和bak表視情況而定，也盡量簡短為宜，命名應使用小寫

字段命名規範

1、字段命名需要表示其實際含義的英文單字或簡寫，單字之間用底線_ 進行連接，如service_ip、service_port。

2、各表之間相同意義的欄位必須同名，例如a表和b表都有創建時間，應該統一為create_time，不一致會很混亂。

3、多個單字以下劃線_ 分隔

4、字段名盡量不超過30個字符，命名應該使用小寫

索引命名規範

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、多個單字以下劃線 _ 分隔。

4、索引名盡量不超過50個字符，命名應該使用小寫，組合索引的字段不宜太多，不然也不利於查詢效率的提升。

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

6、理解組合索引最左前綴原則，避免重複建設索引，如果建立了(a,b,c)，相當於建立了(a), (a,b), (a,b ,c)。

視圖命名規範

1、視圖名稱以v開頭，表示view，完整結構是v 視圖內容意義縮寫。

2、若檢視只來源單一資料表，則為v 表名。如果視圖由幾個表格關聯產生就用v 底線（_）連接幾個表名，視圖名盡量不超過30個字元。如超過30個字元則取簡寫。

3、如無特殊需要，嚴禁開發人員創建視圖。

4、命名應使用小寫。

預存程序命名規範

1、預存程序名稱以sp開頭，表示預存程序（storage procedure）。之後多個單字以下劃線（_）進行連接。在儲存過程命名中應體現其功能。儲存過程名盡量不能超過30個字元。

2、預存程序中的輸入參數以i_開頭，輸出參數以o_開頭。

3、命名應使用小寫。

create procedure sp_multi_param(in i_id bigint,in i_name varchar(32),out o_memo varchar(100))

函數命名規格

1、函數名稱以func開始，表示function。之後多個單字以下劃線（_）進行連接，函數命名中應反映其功能。函數名盡量不超過30個字元。

2、命名應使用小寫。

create function func_format_date(ctime datetime)

觸發器命名規範

1、觸發器以trig開頭，表示trigger 觸發器。

2、基本部分，描述觸發器所加的表，觸發器名稱盡量不超過30個字元。

3、字尾（_i,_u,_d）,表示觸發條件的觸發方式（insert,update或delete）。

4、命名應使用小寫。

DROP TRIGGER IF EXISTS trig_attach_log_d;CREATE TRIGGER trig_attach_log_d AFTER DELETE ON t_dept FOR EACH ROW;

約束命名規格

1、唯一約束：uk_表格名稱_欄位名稱。 uk是UNIQUE KEY的縮寫。例如給一個部門的部門名稱加上唯一約束，來保證不重名，如下：

ALTER TABLE t_dept ADD CONSTRAINT un_name UNIQUE(name);

2、外鍵約束：fk_表名，後面緊跟著該外鍵所在的表名和對應的主表名（不含t_）。子表名和父表名用底線(_)分隔。如下：

ALTER TABLE t_user ADD CONSTRAINT fk_user_dept FOREIGN KEY(depno) REFERENCES t_dept (id);

3、非空約束：如無特殊需要，建議所有欄位預設為非空(not null)，不同資料型別必須給予預設值(default)。

1 `id` int(11) NOT NULL,2 `name` varchar(30) DEFAULT '',3 `deptId` int(11) DEFAULT ,4 `salary` float DEFAULT NULL,

4、出於效能考慮，如無特殊需要，建議不使用外鍵。參照完整性由程式碼控制。這個也是我們普遍的做法，從程式角度進行完整性控制，但是如果不注意，也會產生髒數據。

5、命名應使用小寫。

使用者命名規格

1、生產使用的使用者命名格式為code_應用

2、只讀使用者命名規則為read_應用

資料庫物件設計規格

儲存引擎的選擇

1、如無特殊需求，必須使用innodb儲存引擎。

可以透過 show variables like ‘default_storage_engine‘ 來查看目前預設引擎。主要有MyISAM 和 InnoDB，從5.5版本開始預設使用 InnoDB 引擎。點這裡進行刷題。

基本的差異為：MyISAM類型不支援事務處理等高階處理，而InnoDB類型支援。 MyISAM類型的表強調的是性能，其執行速度比InnoDB類型更快，但是不提供事務支持，而InnoDB提供事務支持以及外部鍵等高級資料庫功能。

字元集的選擇

1、如無特殊要求，必須使用utf8或utf8mb4。

在國內，選擇對中文和各語言支援都非常完善的utf8格式是最好的方式，MySQL在5.5之後增加utf8mb4編碼，mb4就是most bytes 4的意思，專門用來相容四位元組的unicode。

所以utf8mb4是utf8的超集，除了將編碼改為utf8mb4外不需要做其他轉換。當然，為了節省空間，一般情況下使用utf8也就夠了。

可以使用下列腳本來檢視資料庫的編碼格式

1 SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';2 -- 或3 SHOW VARIABLES Like '%char%';

表設計規格

1、不同應用程式間所對應的資料庫表之間的關聯應盡可能減少，不允許使用外鍵對錶之間進行關聯，確保組件對應的表之間的獨立性，為系統或表結構的重構提供可能性。目前業界的做法一般 由程序控制參照完整性。

2、表格設計的角度不應該針對整個系統進行資料庫設計，而應該根據系統架構中元件劃分，針對每個元件所處理的業務進行資料庫設計。

3、表格必須要有PK，主鍵的優勢是唯一識別、有效引用、高效檢索，所以一般情況下盡量有主鍵欄位。

4、一個欄位只表示一個意義。

5、表格不應該有重複列。

6、禁止使用複雜資料類型(數組,自訂等)，Json類型的使用視情況而定。

7、需要join的欄位(連接鍵)，資料型別必須保持絕對一致，避免隱含轉換。例如關聯的欄位都是int型別。

8、設計應至少滿足第三範式,盡量減少資料冗餘。一些特殊場景允許反範式化設計，但在專案評審時需要對冗餘欄位的設計給予解釋。

9、TEXT欄位作為大體量文字存儲，必須放在獨立的表中 , 用PK與主表關聯。如無特殊需要，禁止使用TEXT、BLOB欄位。

10、需要定期刪除(或轉移)過期資料的表，透過分錶解決，我們的做法是按照2/8法則將操作頻率較低的歷史資料遷移到歷史表中，依照時間或則曾Id做切割點。

11、單表字段數不要太多，建議最多不要大於50個。過度的寬表對效能也是很大的影響。

12、MySQL在處理大表時，效能就開始明顯降低，所以建議單表物理大小限制在16GB，表中資料行數控制在2000W內。

業界的規則是超過2000W效能開始明顯降低。但這個數值是彈性的，你可以根據實際情況來測試來判斷，例如阿里的標準就是500W，百度的確是2000W。實際上是否寬表，單行資料所佔用的空間都有起到作用的。

13、如果資料量或資料成長在前期規劃時就較大，那麼在設計評審時就應加入分錶策略，後續會有專門的文章來分析資料拆分的做法：垂直拆分（垂直分庫與垂直分錶）、水平分割（分庫分錶與庫內分錶）；

#14、無特殊需求，嚴禁使用分區表

欄位設計規格

1、INT：如無特殊需要，存放整數數字使用UNSIGNED INT型，整數欄位後的數字代表顯示長度。例如id int(11) NOT NULL

2、DATETIME：所有需要精確到時間(時分秒)的欄位都使用DATETIME,不要使用TIMESTAMP型別。

對於TIMESTAMP，它把寫入的時間從目前時區轉換為UTC（世界標準時間）進行儲存。查詢時，將其轉換為客戶端當前時區進行傳回。而對於DATETIME，不做任何改變，基本上就是原樣輸入和輸出。

另外DATETIME儲存的範圍也比較大：

timestamp所能儲存的時間範圍為：'1970-01-01 00: 00:01.000000' 到'2038-01-19 03:14:07.999999'。

datetime所能儲存的時間範圍為：』1000-01-01 00:00:00.000000’ 到 ‘9999-12-31 23:59:59.999999’。

但是特殊情況，對於跨時區的業務，TIMESTAMP更為合適。

3、VARCHAR：所有動態長度字串全部使用VARCHAR類型,類似於狀態等有限類別的欄位,也使用可以比較明顯表示出實際意義的字串,而不應該使用INT之類的數字來代替；VARCHAR(N)，

N表示的是字元數而不是位元組數。例如VARCHAR(255)，可以最大可儲存255個字元（字元包括英文字母，漢字，特殊字元等）。但N應盡可能小，因為MySQL一個表中所有的VARCHAR字段最大長度是65535個字節，且儲存字元數目由所選字元集決定。

如UTF8儲存一個字元最大要3個字節，那麼varchar在存放佔用3個位元組長度的字元時不應超過21845個字元。同時，在進行排序和建立臨時表一類的記憶體操作時，會使用N的長度申請記憶體。 (如無特殊需要，原則上單一varchar型欄位不允許超過255個字元)

4、TEXT：僅當字元數量可能超過20000個的時候,才可以使用TEXT類型來存放字元類資料,因為所有MySQL資料庫都會使用UTF8字元集。

所有使用TEXT類型的欄位必須和原始表進行分拆，與原始表主鍵單獨組成另外一個表進行存放，與大文本欄位的隔離，目的是。如無特殊需要，不使用MEDIUMTEXT、TEXT、LONGTEXT類型

##5、對於精確浮點型資料存儲，需要使用

DECIMAL，嚴禁使用FLOAT和DOUBLE。

6、如無特殊需要，盡量不使用

BLOB類型

#7、如無特殊需要，欄位建議使用

NOT NULL屬性，可用預設值取代NULL

8、自增欄位類型必須是整數且必須為

UNSIGNED，建議類型為INT或BIGINT，且自增欄位必須是主鍵或主鍵的一部分。

索引設計規格

1、索引區分

#索引必須建立在索引選擇性（區分度）較高的欄位上，選擇性的計算方式為:  

selecttivity = count(distinct c_name)/count(*); 如果區分度結果小於0.2，則不建議在此列上建立索引，否則大機率會拖慢SQL執行

2、遵循最左字首

#####

对于确定需要组成组合索引的多个字段，设计时建议将选择性高的字段靠前放。使用时，组合索引的首字段，必须在where条件中，且需要按照最左前缀规则去匹配。

3、禁止使用外键，可以在程序级别来约束完整性

4、Text类型字段如果需要创建索引，必须使用前缀索引

5、单张表的索引数量理论上应控制在5个以内。经常有大批量插入、更新操作表，应尽量少建索引，索引建立的原则理论上是多读少写的场景。

6、ORDER BY，GROUP BY，DISTINCT的字段需要添加在索引的后面，形成覆盖索引

7、正确理解和计算索引字段的区分度，文中有计算规则，区分度高的索引，可以快速得定位数据，区分度太低，无法有效的利用索引，可能需要扫描大量数据页，和不使用索引没什么差别。

8、正确理解和计算前缀索引的字段长度，文中有判断规则，合适的长度要保证高的区分度和最恰当的索引存储容量，只有达到最佳状态，才是保证高效率的索引。

9、联合索引注意最左匹配原则：必须按照从左到右的顺序匹配，MySQL会一直向右匹配索引直到遇到范围查询(>、between、like)然后停止匹配。

如：depno=1 and empname>'' and job=1 如果建立(depno,empname,job)顺序的索引，job是用不到索引的。

10、应需而取策略，查询记录的时候，不要一上来就使用*，只取需要的数据，可能的话尽量只利用索引覆盖，可以减少回表操作，提升效率。

11、正确判断是否使用联合索引（上面联合索引的使用那一小节有说明判断规则），也可以进一步分析到索引下推（IPC），减少回表操作，提升效率。

12、避免索引失效的原则：禁止对索引字段使用函数、运算符操作，会使索引失效。这是实际上就是需要保证索引所对应字段的”干净度“。

13、避免非必要的类型转换，字符串字段使用数值进行比较的时候会导致索引无效。

14、模糊查询’%value%’会使索引无效，变为全表扫描，因为无法判断扫描的区间，但是’value%’是可以有效利用索引。

15、索引覆盖排序字段，这样可以减少排序步骤，提升查询效率

16、尽量的扩展索引，非必要不新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。

举例子：比如一个品牌表，建立的的索引如下，一个主键索引，一个唯一索引

1 PRIMARY KEY (`id`),2 UNIQUE KEY `uni_brand_define` (`app_id`,`define_id`)

当你同事业务代码中的检索语句如下的时候，应该立即警告了，即没有覆盖索引，也没按照最左前缀原则：

1 select brand_id,brand_name from  ds_brand_system where status=?  and define_id=?  and app_id=?

建议改成如下：

1 select brand_id,brand_name from  ds_brand_system where app_id=? and define_id=?  and  status=?

约束设计规范

1、PK应该是有序并且无意义的，由开发人员自定义，尽可能简短，并且是自增序列。

2、表中除PK以外,还存在唯一性约束的,可以在数据库中创建以“uk_”作为前缀的唯一约束索引。

3、PK字段不允许更新。

4、禁止创建外键约束，外键约束由程序控制。

5、如无特殊需要，所有字段必须添加非空约束，即not null。

6、如无特殊需要，所有字段必须有默认值。

SQL使用规范

select 检索的规范性

1、尽量避免使用select *，join语句使用select *可能导致只需要访问索引即可完成的查询需要回表取数。

一种是可能取出很多不需要的数据，对于宽表来说，这是灾难；一种是尽可能避免回表，因为取一些根本不需要的数据而回表导致性能低下，是很不合算。

2、严禁使用 select * from t_name ，而不加任何where条件，道理一样，这样会变成全表全字段扫描。

3、MySQL中的text类型字段存储：

3.1、不与其他普通字段存放在一起,因为读取效率低，也会影响其他轻量字段存取效率。

3.2、如果不需要text类型字段，又使用了select *，会让该执行消耗大量io，效率也很低下

4、在取出欄位上可以使用相關函數，但應盡可能避免出現now() , rand() , sysdate() 等不確定結果的函數，在Where條件中的過濾條件欄位上嚴禁使用任何函數，包括資料類型轉換函數。大量的計算和轉換會造成效率低下，這個在索引那邊也描述過了。

5、分頁查詢語句全部都需要帶有排序條件, 否則很容易引起亂序

6、用in()/union替換or ，效率會好一些，並注意in的個數小於300

7、嚴禁使用%前綴進行模糊前綴查詢:如：select a,b,c from t_name where a like '%name'; 可以使用%模糊後綴查詢如：select a,b from t_name where a like 'name%';

#8、避免使用子查詢，可以把子查詢優化為join操作

通常子查詢在in子句中，且子查詢中為簡單SQL(不包含union、group by、order by、limit子句)時，才可以把子查詢轉換成關聯查詢進行最佳化。

子查詢效能差的原因：

· 子查詢的結果集無法使用索引，通常子查詢的結果集就會儲存到暫存表中，不論是記憶體臨時表或磁碟暫存表都不會存在索引，所以查詢效能會受到一定的影響；

· 特別是對於傳回結果集比較大的子查詢，其對查詢效能的影響也就越大；

· 由於子查詢會產生大量的臨時表也沒有索引，所以會消耗過多的CPU和IO資源，產生大量的慢查詢。

運算的規範

1、禁止使用不含欄位清單的INSERT語句

如： insert into values ('a','b','c');  應使用insert into t_name(c1,c2,c3) values ('a','b','c'); 。

2、大批量寫入操作（UPDATE、DELETE、INSERT），需要分批多次進行動作

· 大批量操作可能會造成嚴重的主從延遲，特別是主從模式下，大批量操作可能會造成嚴重的主從延遲，因為需要slave#master的binlog中讀取日誌來進行資料同步。

· binlog日誌為row格式時會產生大量的日誌

以上是最詳細的MySQ設計與開發規格【推薦收藏】的詳細內容。更多資訊請關注PHP中文網其他相關文章！