1.數據庫設計

1.1庫名

1.庫的名稱盡量控制在32個字符以內，最長不超過64個字符，相關模塊的表名與表名之間盡量體現join的關系，如user表和user_login表。庫名建議不要使用MySQL保留字。如ic_u_payment_prod_db,為創新中心unex payment項目。

2.庫的名稱格式：業務系統名稱_子系統名，同一模塊使用的表名盡量使用統一前綴。

3.一般分庫名稱命名格式是“庫通配名_編號”，編號從“1”開始遞增，比如“wenda_001”,以時間進行分庫的名稱格式是“庫通配名_時間”

4.創建數據庫時必須顯式指定字符集，并且字符集只能是utf8。

創建數據庫SQL舉例：Create database db1 default character set utf8 COLLATE utf8_general_ci;

1.2表結構

1.表和字段的名稱盡量控制在32個字符以內，最長不超過64個字符。表名只能使用字母、數字和下劃線，一律小寫。表名建議不使用MySQL保留字。

2.表名要求模塊名強相關，如支付系統采用”payment”作為前綴。

3.創建表時必須顯式指定字符集為utf8，DEFAULT CHARSET=utf8。

4.創建表時必須顯式指定表存儲引擎類型，ENGINE=xxxx，如無特殊需求，一律為InnoDB。

因為Innodb表支持事務、行鎖、宕機恢復、MVCC等關系型數據庫重要特性，為業界使用最多的MySQL存儲引擎。而這是其他大多數存儲引擎不具備的，因此首推InnoDB。

5.建表必須有comment，方便其他人理解表結構，進而理解業務。

6.建表時關于主鍵：

推薦開發的同事們使用和業務沒有任何關聯的自增id來做主鍵(切記不要使用uuid來做主鍵)，類型為int或bigint，且為auto_increment

因為如果設為主鍵且主鍵值為隨機插入，則會導致InnoDB內部page分裂和大量隨機I/O，性能下降。

7.核心表(如用戶表，金錢相關的表)必須有行數據的創建時間字段create_time和最后更新時間字段update_time，便于查問題。

8.表中所有字段建議都是NOT NULL屬性，業務可以根據需要定義DEFAULT值，如空字符串‘’，或者‘0’。

因為使用NULL值會存在每一行都會占用額外存儲空間、數據遷移容易出錯、聚合函數計算結果偏差等問題。

如果此列為NULL，需要添加索引，則必須更改為NOT NULL，如果不需要添加索引，可以暫時不處理。

9.建議對表里的blob、text等大字段，根據主鍵拆分到其他表中，僅在需要讀這些對象的時候才去select。

10.反范式設計：把經常需要join查詢的字段，在其他表里冗余一份。如user_name屬性在user_account，user_login_log等表里冗余一份，減少join查詢。

11.中間表用于保留中間結果集，名稱必須以“tmp_”開頭。備份表用于備份或抓取源表快照，名稱必須以“bak_”開頭。

中間表和備份表定期清理。

12.對于超過100W行的大表進行alter table，必須在業務低峰期執行,并使用PT-OSC工具執行。

因為alter table會產生MDL鎖，期間阻塞對于該表的所有寫入，對于業務可能會產生極大影響。

1.3數據類型優化

1.表中的自增列(auto_increment屬性)，推薦使用bigint類型。

因為無符號int存儲范圍為0-4294967295(大約42億左右)，溢出后會導致報錯。

2.業務中選擇性很少的狀態status、類型type等字段推薦使用tinytint或者smallint類型節省存儲空間。

3.業務中IP地址字段推薦使用Unsigned int類型，不推薦用char(15)

因為int只占4字節，可以用如下函數相互轉換，而char(15)占用至少15字節。一旦表數據行數到了1億，那么要多用1.1G存儲空間！

SQL：select inet_aton('192.168.2.12'); select inet_ntoa(3232236044);

Php:ip2long(‘192.168.2.12’); long2ip(3530427185);

4.不推薦使用enum，set

因為它們浪費空間，且枚舉值寫死了，變更不方便，需要用PT-OCS工具修改。推薦使用tinyint。

5.不推薦使用blob，text等類型

它們都比較浪費硬盤和內存空間。在加載表數據時，會讀取大字段到內存里從而浪費內存空間，影響系統性能。如果有需求使用，請單獨建表，用主鍵與相關表關聯。

6.存儲金錢的字段，數據量小，使用decimal，并指定具體的長度，如decimal(19,3)。數據量大，建議用bigint，程序端乘以100和除以100進行存取。

7.文本數據盡量用varchar存儲

因為varchar是變長存儲，比char更省空間。MySQL server層規定一行所有文本最多存65535字節，因此在utf8字符集下最多存21844個字符，超過會自動轉換為mediumtext字段。而text在utf8字符集下最多存21844個字符，mediumtext最多存2^24/3個字符，longtext最多存2^32個字符。

8.varchar(255)與varchar(20)都可以滿足時，請使用varchar(20)

這么做的好處是：更小的字段類型占用更少的內存，占用更少的磁盤空間，占用更少的磁盤IO，以及占用更少的帶寬。舉個例子，如果一個varchar(50)的字段，不管你存儲了幾個字符，在查詢的時候仍然需要申請50 byte的內存

9.時間類型盡量選取datetime

因為在MySQL5.6之后，datetime占用5字節，時間范圍：1000-01-01 00:00:00 ~ 9999-12-31 23:59:59，

在timestamp占用4字節，時間范圍：1970-01-01 00:00:01~2038-01-01 00:00:00，值以UTC格式保存，涉及時區轉化 ，存儲時對當前的時區進行轉換，檢索時再轉換回當前的時區。

MySQL5.6.5開始均支持自動更新為current_timestamp

更為高階的方法，選用int來存儲時間，使用SQL函數unix_timestamp()和from_unixtime()來進行轉換。

1.4索引設計

1.InnoDB表必須主鍵為id

int/bigint auto_increment,且主鍵值禁止被更新。

2.主鍵的名稱以“pk_”開頭，唯一鍵以“uk_”開頭，普通索引以“idx_”開頭，一律使用小寫格式，以字段的名稱或縮寫作為后綴。

3.InnoDB存儲引擎表，索引類型必須為BTREE；MEMORY表可以根據需要選擇HASH或者BTREE類型索引。

4.單個索引中每個索引記錄的長度不能超過64KB

5.單個表上的索引個數不能超過7個

6.單個索引中的字段不超過5個

7.在建立索引時，多考慮建立聯合索引，并把區分度最高的字段放在最前面。如列userid的區分度可由select count(distinct userid)/select count(*)計算出來。

8.在多表join的SQL里，建議被驅動表的連接列上有索引，這樣join執行效率最高。

9.建表或加索引時，保證表里互相不存在冗余索引。

對于MySQL來說，如果表里已經存在key(a,b)，則key(a)為冗余索引，需要刪除。

10.不建議使用外鍵。

11.不在低基數列上建立索引，例如性別。

1.5分庫分表、分區表

1.不建議使用分區表。分區表對分區鍵有嚴格要求；分區表在表變大后，執行DDL、SHARDING、單表恢復等都變得更加困難。因此 不建議使用分區表，并建議業務端?手動SHARDING。

2.采用分庫策略的，庫的數量不能超過1024

3.采用分表策略的，表的數量不能超過4096

4.單個分表不超過500W行，ibd文件大小不超過2G，這樣才能讓數據分布式變得性能更佳。

5.水平分表盡量用取模方式，日志、報表類數據建議采用日期進行分表。

1.6字符集

1.數據庫本身庫、表、列所有字符集必須保持一致，為utf8。

2.前端程序字符集或者環境變量中的字符集，與數據庫、表的字符集必須一致，統一為utf8

1.7 程序DAO層設計建議

1.新的代碼不要用model，推薦使用手動拼SQL+綁定變量傳入參數的方式。

因為model雖然可以使用面向對象的方式操作db，但是其使用不當很容易造成生成的SQL非常復雜，且model層自己做的強制類型轉換性能較差，最終導致數據庫性能下降。

2.前端程序連接MySQL或者redis，必須要有連接超時和失敗重連機制，且失敗重試必須有間隔時間。

3.前端程序報錯里盡量能夠提示MySQL或redis原生態的報錯信息，便于排查錯誤。

4.對于有連接池的前端程序，必須根據業務需要配置初始、最小、最大連接數，超時時間以及連接回收機制，否則會耗盡數據庫連接資源，造成線上事故。

5.對于log或history類型的表，隨時間增長容易越來越大，因此上線前必須建立表數據清理或歸檔方案。

6.在應用程序設計階段，RD必須考慮并規避數據庫中主從延遲對于業務的影響。盡量避免從庫短時延遲(20秒以內)對業務造成影響，建議強制一致性的讀開啟事務走主庫，或更新后過一段時間再去讀從庫。

7.多個并發業務邏輯訪問同一塊數據(innodb表)時，會在數據庫端產生行鎖甚至表鎖導致并發下降，因此建議更新類SQL盡量基于主鍵去更新。

8.業務邏輯之間加鎖順序盡量保持一致，否則會導致死鎖。

9.對于單表讀寫比大于10:1的數據行或單個列，可以將熱點數據放在緩存里(如mecache或redis)，加快訪問速度，降低MySQL壓力。

1.8一個規范的建表語句示例

一個較為規范的建表語句為：CREATE TABLE `user` (

`id` bigint NOT NULL AUTO_INCREMENT,

`user_id` bigint NOT NULL COMMENT '用戶id',

`username` varchar(45) NOT NULL?DEFAULT '' COMMENT '真實姓名',

`email` varchar(30) NOT NULL DEFAULT '' COMMENT '用戶郵箱',

`nickname` varchar(45) NOT NULL?DEFAULT '' COMMENT '昵稱',

`birthday` date NOT NULL DEFAULT '19000101' COMMENT '生日',

`sex` tinyint DEFAULT '0' COMMENT '性別',

`short_introduce` varchar(150) DEFAULT NULL COMMENT '一句話介紹自己，最多150個漢字',

`user_resume` varchar(300) NOT NULL?DEFAULT'' COMMENT '用戶提交的簡歷存放地址',

`user_register_ip` int unsigned? NULL? COMMENT '用戶注冊時的源ip',

`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '用戶記錄創建的時間',

`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '用戶資料修改的時間',

`user_review_status` tinyint(4) NOT NULL DEFAULT '4' COMMENT '用戶資料審核狀態，1為通過，2為審核中，3為未通過，4為還未提交審核',

PRIMARY KEY (`id`),

UNIQUE KEY `uk_user_id` (`user_id`),

KEY `idx_username` (`username`),

KEY `idx_create_time` (`create_time`,`user_review_status`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='網站用戶基本信息';

2.SQL編寫

2.1DML語句

1.SELECT語句必須指定具體字段名稱，禁止寫成“*”，因為select *會將不該讀的數據也從MySQL里讀出來，造成網卡壓力。且表字段一旦更新，但model層沒有來得及更新的話，系統會報錯。

2.insert語句指定具體字段名稱，不要寫成insert into t1 values(…)，道理同上。

3.insert into…values(XX),(XX),(XX)..這里XX的值不要超過5000個。

值過多雖然執行很快，但是這是個大事物，容易引起主從同步延遲。

4.SELECT語句不要使用UNION，推薦使用UNION ALL，并且UNION子句個數限制在5個以內。

因為union all不需要去重，節省數據庫資源，提高性能。

5.in值列表建議限制在500以內。

例如select…where userid in(….500個以內…)，這么做是為了減少底層掃描，減輕數據庫壓力從而加速查詢。

6.事務里批量更新數據需要控制數量，進行必要的sleep，做到少量多次。

7.事務涉及的表必須全部是innodb表。

否則一旦失敗不會全部回滾，且易造成主從庫同步中斷。

8.寫入和事務發往主庫，只讀SQL發往從庫。

9.除靜態表或小表(100行以內)，DML語句必須有where條件，且使用索引查找。

10.生產環境禁止使用hint，如sql_no_cache，force index，ignore key，straight join等。

因為hint是用來強制SQL按照某個執行計劃來執行，但隨著數據量變化我們無法保證自己當初的預判是正確的，因此我們要相信MySQL優化器！

11.where條件里等號左右字段類型必須一致，否則無法利用索引。

12.SELECT|UPDATE|DELETE|REPLACE要有WHERE子句，且WHERE子句的條件必需使用索引查找。

13.生產數據庫中強烈不推薦大表上發生全表掃描，但對于100行以下的靜態表可以全表掃描。查詢數據量不要超過表行數的25%，否則不會利用索引。

14.WHERE子句中禁止只使用全模糊的LIKE條件進行查找，必須有其他等值或范圍查詢條件，否則無法利用索引。

15.索引列不要使用函數或表達式，否則無法利用索引。如where length(name)=’Admin’

或where user_id+2=10023

16.禁止隱式轉換。數值類型禁止加引號；字符串類型必須加引號。

17.分頁查詢，當limit起點較高時，可先用過濾條件進行過濾。

如select a,b,c from t1 limit 10000,20;

優化為:select a,b,c from t1 where id>10000 limit 20;

18.禁止使用%前導查詢，例如：like '%abc',有可能會無法使用索引，可以使用‘abc%'。

19.禁止使用負向查詢，例如：not in、！=、not like。

20.禁止使用order by rand()。

order by rand()會為表增加?個偽列，然后?rand()函數為每??數據計算出rand()值，然后基于該?排序， 這通常都會生成磁盤上的臨時表，因此效率非常低。建議先使用rand()函數獲得隨機的主鍵值，然后通過主鍵 獲取數據。

2.2多表連接

1.禁止跨db的join語句。

因為這樣可以減少模塊間耦合，為數據庫拆分奠定堅實基礎。

2.禁止在業務的更新類SQL語句中使用join，比如update t1 join t2…

3.不建議使用子查詢，建議將子查詢SQL拆開結合程序多次查詢，或使用join來代替子查詢。

4.線上環境，多表join建議不要超過3個表。

5.多表連接查詢推薦使用別名，且SELECT列表中要用別名引用字段，數據庫.表格式，如select a from db1.table1 alias1 where …

6.在多表join中，盡量選取結果集較小的表作為驅動表，來join其他表。

7.上次討論說是盡量不適用表連接。。

2.3事務

1.建議事務中INSERT|UPDATE|DELETE|REPLACE語句操作的行數控制在2000以內，以及WHERE子句中IN列表的傳參個數控制在500以內。

2.批量操作數據時，需要控制事務處理間隔時間，進行必要的sleep，一般建議值5-10秒。

3.對于有auto_increment屬性字段的表的插入操作，并發需要控制在200以內。

4.程序設計必須考慮“數據庫事務隔離級別”帶來的影響，包括臟讀、不可重復讀和幻讀。線上建議事務隔離級別為repeatable-read

5.事務里包含SQL不超過5個(支付業務除外)

因為過長的事務會導致鎖數據較久，MySQL內部緩存、連接消耗過多等雪崩問題。

6.事務里更新語句盡量基于主鍵或unique key，如update … where id=XX;

否則會產生間隙鎖，內部擴大鎖定范圍，導致系統性能下降，產生死鎖。

7.盡量把一些典型外部調用移出事務，如調用webservice，訪問文件存儲等，從而避免事務過長。

8.對于MySQL主從延遲嚴格敏感的select語句，請開啟事務強制訪問主庫。

2.4排序和分組

1.減少使用order by，和業務溝通能不排序就不排序，或將排序放到程序端去做。Order by、group by、distinct這些語句較為耗費CPU，數據庫的CPU資源是極其寶貴的。

2.order by、group by、distinct這些SQL盡量利用索引直接檢索出排序好的數據。如where a=1 order by b可以利用key(a,b)。

3.包含了order by、group by、distinct這些查詢的語句，where條件過濾出來的結果集請保持在1000行以內，否則SQL會很慢。

2.5 線上禁止使用的SQL語句

1.禁用update|delete t1 … where a=XX limit XX;

這種帶limit的更新語句。

因為會導致主從不一致，導致數據錯亂。建議加上order by PK

2.禁止使用關聯子查詢，如update t1 set … where name in(select name from user where…);

效率極其低下。

3.禁用procedure、function、trigger、views、event、外鍵約束。

因為他們消耗數據庫資源，降低數據庫集群可擴展性。推薦都在程序端實現。

4.禁用insert into …on duplicate key update…

在高并發環境下，會造成主從不一致。

5.禁止聯表更新語句，如update t1,t2 where t1.id=t2.id…

總結

以上是生活随笔為你收集整理的mysql数据库名长可为64字符,MySQL数据库设计规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。