以下這篇文章為大家整理最詳細的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
類型
DECIMAL,嚴禁使用
FLOAT和
DOUBLE。
BLOB類型
NOT NULL屬性,可用預設值取代
NULL
UNSIGNED,建議類型為
INT或
BIGINT,且自增欄位必須是主鍵或主鍵的一部分。
selecttivity = count(distinct c_name)/count(*); 如果區分度結果小於0.2,則不建議在此列上建立索引,否則大機率會拖慢SQL執行
对于确定需要组成组合索引的多个字段,设计时建议将选择性高的字段靠前放。使用时,组合索引的首字段,必须在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 如果建立(<code>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、如无特殊需要,所有字段必须有默认值。
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中文網其他相關文章!