MySQL命名、設計及使用規範--------來自標點符的《MySQL命名、設計及使用規範》

時間 2019-11-13

標籤 mysql 命名設計使用規範來自標點欄目 MySQL 简体版

原文原文鏈接

原文地址：http://www.biaodianfu.com/mysql-best-practices.htmlphp

最近在看MySQL相關的內容，整理以下規範，做爲一名剛剛學習MySQL的菜鳥，整理的內容很是的基礎，中間可能涉及到有錯誤的地方，歡迎批評指正，看到有錯誤的地方指望看官留言。html

數據庫環境

dev：開發環境，開發可讀寫，可修改表結構。開發人員能夠修改表結構，能夠隨意修改其中的數據可是須要保證不影響其餘開發同事。
qa：測試環境，開發可讀寫，開發人員能夠經過工具修改表結構。
sim：模擬環境，開發可讀寫，發起上線請求時，會先在這個環境上進行預執行，這個環境也可供部署上線演練或壓力測試使用。
real：生產數據庫從庫（準實時同步），只讀環境，不容許修改數據，不容許修改表結構，供線上問題查找，數據查詢等使用。
online：線上環境，開發人員不容許直接在線上環境進行數據庫操做，若是須要操做必須找DBA進行操做並進行相應記錄，禁止進行壓力測試。

這些環境的機器，必定要作到權限劃分明確，讀寫賬號分離，而且有辨識度，能區分具體業務。例如用戶名w_account，r_ account 分別表明讀、寫帳號，account是讀寫帳號。mysql

命名規範

基本命名原則git

使用有意義的英文詞彙，詞彙中間如下劃線分隔。（不要用拼音）
只能使用英文字母，數字，下劃線，並以英文字母開頭。
庫、表、字段所有采用小寫，不要使用駝峯式命名。
避免用ORACLE、MySQL的保留字，如desc，關鍵字如index。
命名禁止超過32個字符，須見名之意，建議使用名詞不是動詞
數據庫，數據表一概使用前綴
- 臨時庫、表名必須以tmp爲前綴，並以日期爲後綴
- 備份庫、表必須以bak爲前綴，並以日期爲後綴

爲何庫、表、字段所有采用小寫？github

在 MySQL 中，數據庫和表對就於那些目錄下的目錄和文件。於是，操做系統的敏感性決定數據庫和表命名的大小寫敏感。sql

Windows下是不區分大小寫的。

Linux下大小寫規則：

數據庫名與表名是嚴格區分大小寫的；

表的別名是嚴格區分大小寫的；

列名與列的別名在全部的狀況下均是忽略大小寫的；

變量名也是嚴格區分大小寫的；

若是已經設置了駝峯式的命名如何解決？須要在MySQL的配置文件my.ini中增長 lower_case_table_names = 1便可。數據庫

表命名後端

同一個模塊的表儘量使用相同的前綴，表名稱儘量表達含義。全部日誌表均以 log_ 開頭

字段命名緩存

表達其實際含義的英文單詞或簡寫。布爾意義的字段以「is_」做爲前綴，後接動詞過去分詞。
各表之間相贊成義的字段應同名。各表之間相贊成義的字段，以去掉模塊前綴的表名_字段名命名。
外鍵字段用表名_字段名錶示其關聯關係。
表的主鍵通常都約定成爲id，自增類型，是別的表的外鍵均使用xxx_id的方式來代表。

索引命名網絡

非惟一索引必須按照「idx_字段名稱_字段名稱[_字段名]」進行命名
惟一索引必須按照「uniq_字段名稱_字段名稱[_字段名]」進行命名

約束命名

主鍵約束：pk_表名稱。
惟一約束：uk_表名稱_字段名。（應用中須要同時有惟一性檢查邏輯。）

觸發器命名

trg_表名_操做。

函數過程命名

採用動詞+名詞的形式表達其含義。

序列命名

seq_表名

表設計規範

一、表引擎取決於實際應用場景；日誌及報表類表建議用myisam，與交易，審覈，金額相關的表建議用innodb引擎。如無說明，建表時一概採用innodb引擎。myisam與innodb的區別

二、默認使用utf8mb4字符集，數據庫排序規則使用utf8mb4_general_ci，（因爲數據庫定義使用了默認，數據表能夠再也不定義，但爲保險起見，建議都寫上）。

爲何字符集不選擇utf8，排序規則不使用utf8_general_ci？

採用utf8編碼的MySQL沒法保存佔位是4個字節的Emoji表情。爲了使後端的項目，全面支持客戶端輸入的Emoji表情，升級編碼爲utf8mb4是最佳解決方案。對於JDBC鏈接串設置了characterEncoding爲utf8或者作了上述配置仍舊沒法正常插入emoji數據的狀況，須要在代碼中指定鏈接的字符集爲utf8mb4。

三、全部表、字段均應用 comment 列屬性來描述此表、字段所表明的真正含義，如枚舉值則建議將該字段中使用的內容都定義出來。

四、如無說明，表中的第一個id字段必定是主鍵且爲自動增加，禁止在非事務內做爲上下文做爲條件進行數據傳遞。禁止使用varchar類型做爲主鍵語句設計。

五、如無說明，表必須包含create_time和modify_time字段，即表必須包含記錄建立時間和修改時間的字段

六、如無說明，表必須包含is_del，用來標示數據是否被刪除，原則上數據庫數據不容許物理刪除。

七、用盡可能少的存儲空間來存數一個字段的數據

能用int的就不用char或者varchar
能用tinyint的就不用int
使用UNSIGNED存儲非負數值。
不建議使用ENUM、SET類型，使用TINYINT來代替
使用短數據類型，好比取值範圍爲0-80時，使用TINYINT UNSIGNED
存儲精確浮點數必須使用DECIMAL替代FLOAT和DOUBLE
時間字段，除特殊狀況一概採用int來記錄unix_timestamp
- 存儲年使用YEAR類型。
- 存儲日期使用DATE類型。
- 存儲時間（精確到秒）建議使用TIMESTAMP類型，由於TIMESTAMP使用4字節，DATETIME使用8個字節。
建議使用INT UNSIGNED存儲IPV4。
儘量不使用TEXT、BLOB類型
禁止在數據庫中使用VARBINARY、BLOB存儲圖片、文件等。建議使用其餘方式存儲（TFS/SFS），MySQL只保存指針信息。
單條記錄大小禁止超過8k（列長度(中文)*3(UTF8)+列長度(英文)*1）

datetime與timestamp有什麼不一樣？

相同點：TIMESTAMP列的顯示格式與DATETIME列相同。顯示寬度固定在19字符，而且格式爲YYYY-MM-DD HH:MM:SS。
不一樣點：

TIMESTAMP

4個字節儲存，時間範圍：1970-01-01 08:00:01 ~ 2038-01-19 11:14:07

值以UTC格式保存，涉及時區轉化，存儲時對當前的時區進行轉換，檢索時再轉換回當前的時區。

datetime

8個字節儲存，時間範圍：1000-01-01 00:00:00 ~ 9999-12-31 23:59:59

實際格式儲存，與時區無關

如何使用TIMESTAMP的自動賦值屬性？

將當前時間做爲ts的默認值：ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP。

當行更新時，更新ts的值：ts TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP。

能夠將1和2結合起來：ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。

如何使用INT UNSIGNED存儲ip？

使用INT UNSIGNED而不是char(15)來存儲ipv4地址，經過MySQL函數inet_ntoa和inet_aton來進行轉化。Ipv6地址目前沒有轉化函數，須要使用DECIMAL或者兩個bigINT來存儲。

八、如無備註，全部字段都設置NOT NULL，並設置默認值；

九、禁止在數據庫中存儲明文密碼

十、如無備註，全部的布爾值字段，如is_hot、is_deleted，都必須設置一個默認值，並設爲0；

十一、如無備註，排序字段order_id在程序中默認使用降序排列；

十二、整形定義中不添加長度，好比使用INT，而不是INT[4]

INT[M]，M值表明什麼含義？

注意數值類型括號後面的數字只是表示寬度而跟存儲範圍沒有關係。不少人他們認爲INT(4)和INT(10)其取值範圍分別是 (-9999到9999)和(-9999999999到9999999999)，這種理解是錯誤的。其實對整型中的 M值與 ZEROFILL 屬性結合使用時能夠實現列值等寬。無論INT[M]中M值是多少，其取值範圍仍是 (-2147483648到2147483647 有符號時)，(0到4294967295無符號時)。

顯示寬度並不限制能夠在列內保存的值的範圍，也不限制超過列的指定寬度的值的顯示。當結合可選擴展屬性ZEROFILL使用時默認補充的空格用零代替。例如：對於聲明爲INT(5) ZEROFILL的列，值4檢索爲00004。請注意若是在整數列保存超過顯示寬度的一個值，當MySQL爲複雜聯接生成臨時表時會遇到問題，由於在這些狀況下MySQL相信數據適合原列寬度，若是爲一個數值列指定ZEROFILL, MySQL自動爲該列添加UNSIGNED屬性。

1三、使用VARBINARY存儲大小寫敏感的變長字符串

何時用CHAR，何時用VARCHAR？

CHAR和VARCHAR類型相似，但它們保存和檢索的方式不一樣。它們的最大長度和是否尾部空格被保留等方面也不一樣。CHAR和VARCHAR類型聲明的長度表示你想要保存的最大字符數。例如，CHAR(30)能夠佔用30個字符。

CHAR列的長度固定爲建立表時聲明的長度。長度能夠爲從0到255的任何值。當保存CHAR值時，在它們的右邊填充空格以達到指定的長度。當檢索到CHAR值時，尾部的空格被刪除掉。在存儲或檢索過程當中不進行大小寫轉換。

VARCHAR列中的值爲可變長字符串。長度能夠指定爲0到65,535之間的值。(VARCHAR的最大有效長度由最大行大小和使用的字符集肯定。總體最大長度是65,532字節）。

同CHAR對比，VARCHAR值保存時只保存須要的字符數，另加一個字節來記錄長度(若是列聲明的長度超過255，則使用兩個字節)。VARCHAR值保存時不進行填充。當值保存和檢索時尾部的空格仍保留，符合標準SQL。

char適合存儲用戶密碼的MD5哈希值，它的長度老是同樣的。對於常常改變的值，char也好於varchar,由於固定長度的行不容易產生碎片，對於很短的列，char的效率也高於varchar。char(1)字符串對於單字節字符集只會佔用一個字節，可是varchar(1)則會佔用2個字節，由於1個字節用來存儲長度信息。

索引設計規範

MySQL的查詢速度依賴良好的索引設計，所以索引對於高性能相當重要。合理的索引會加快查詢速度（包括UPDATE和DELETE的速度，MySQL會將包含該行的page加載到內存中，而後進行UPDATE或者DELETE操做），不合理的索引會下降速度。MySQL索引查找相似於新華字典的拼音和部首查找，當拼音和部首索引不存在時，只能經過一頁一頁的翻頁來查找。當MySQL查詢不能使用索引時，MySQL會進行全表掃描，會消耗大量的IO。索引的用途：去重、加速定位、避免排序、覆蓋索引。

什麼是覆蓋索引？

InnoDB存儲引擎中，secondary index（非主鍵索引）中沒有直接存儲行地址，存儲主鍵值。若是用戶須要查詢secondary index中所不包含的數據列時，須要先經過secondary index查找到主鍵值，而後再經過主鍵查詢到其餘數據列，所以須要查詢兩次。覆蓋索引的概念就是查詢能夠經過在一個索引中完成，覆蓋索引效率會比較高，主鍵查詢是自然的覆蓋索引。合理的建立索引以及合理的使用查詢語句，當使用到覆蓋索引時能夠得到性能提高。好比SELECT email,uid FROM user_email WHERE uid=xx，若是uid不是主鍵，適當時候能夠將索引添加爲index(uid,email)，以得到性能提高。

索引的基本規範

一、索引數量控制，單張表中索引數量不超過5個，單個索引中的字段數不超過5個。

綜合評估數據密度和分佈
考慮查詢和更新比例

爲何一張表中不能存在過多的索引？

InnoDB的secondary index使用b+tree來存儲，所以在UPDATE、DELETE、INSERT的時候須要對b+tree進行調整，過多的索引會減慢更新的速度。

二、對字符串使用前綴索引，前綴索引長度不超過8個字符，建議優先考慮前綴索引，必要時可添加僞列並創建索引。

不要索引blob/text等字段,不要索引大型字段,這樣作會讓索引佔用太多的存儲空間

什麼是前綴索引？

前綴索引說白了就是對文本的前幾個字符（具體是幾個字符在創建索引時指定）創建索引，這樣創建起來的索引更小，因此查詢更快。前綴索引能有效減少索引文件的大小，提升索引的速度。可是前綴索引也有它的壞處：MySQL 不能在 ORDER BY 或 GROUP BY 中使用前綴索引，也不能把它們用做覆蓋索引(Covering Index)。

創建前綴索引的語法：ALTER TABLE table_name ADD KEY(column_name(prefix_length));

三、主鍵準則

表必須有主鍵
不使用更新頻繁的列
儘可能不選擇字符串列
不使用UUID MD5 HASH
默認使用非空的惟一鍵
建議選擇自增或發號器

四、重要的SQL必須被索引，核心SQL優先考慮覆蓋索索引

UPDATE、DELETE語句的WHERE條件列
ORDER BY、GROUP BY、DISTINCT的字段
多表JOIN的字段

五、區分度最大的字段放在前面

選擇篩選性更優的字段放在最前面，好比單號、userid等，type，status等篩選性通常不建議放在最前面
索引根據左前綴原則，當創建一個聯合索引(a,b,c)，則查詢條件裏面只有包含(a)或(a,b)或(a,b,c)的時候才能走索引,(a,c)做爲條件的時候只能使用到a列索引,因此這個時候要肯定a的返回列必定不能太多，否則語句設計就不合理,(b,c)則不能走索引
合理建立聯合索引（避免冗餘），(a,b,c) 至關於 (a) 、(a,b) 、(a,b,c)

六、索引禁忌

不在低基數列上創建索引，例如「性別」
不在索引列進行數學運算和函數運算
不要索引經常使用的小型表

七、儘可能不使用外鍵

外鍵用來保護參照完整性，可在業務端實現
對父表和子表的操做會相互影響，下降可用性
INNODB自己對online DDL的限制

MYSQL 中索引的限制

MYISAM 存儲引擎索引長度的總和不能超過 1000 字節
BLOB 和 TEXT 類型的列只能建立前綴索引
MYSQL 目前不支持函數索引
使用不等於 (!= 或者 <>) 的時候, MYSQL 沒法使用索引。
過濾字段使用函數運算 (如 abs (column)) 後, MYSQL沒法使用索引。
join語句中join條件字段類型不一致的時候MYSQL沒法使用索引
使用 LIKE 操做的時候若是條件以通配符開始 (如 ‘%abc…’)時, MYSQL沒法使用索引。
使用非等值查詢的時候, MYSQL 沒法使用 Hash 索引。

語句設計規範

一、使用預編譯語句

只傳參數，比傳遞SQL語句更高效
一次解析，屢次使用
下降SQL注入機率

二、避免隱式轉換

會致使索引失效

三、充分利用前綴索引

必須是最左前綴
不可能同時用到兩個範圍條件
不使用%前導的查詢，如like 「%ab」

四、不使用負向查詢，如not in/like

沒法使用索引，致使全表掃描
全表掃描致使buffer pool利用率下降

五、避免使用存儲過程、觸發器、UDF、events等

讓數據庫作最擅長的事
下降業務耦合度，爲sacle out、sharding留有餘地
避開BUG

六、避免使用大表的JOIN

MySQL最擅長的是單表的主鍵/二級索引查詢
JOIN消耗較多內存，產生臨時表

七、避免在數據庫中進行數學運算

MySQL不擅長數學運算和邏輯判斷
沒法使用索引

七、減小與數據庫的交互次數

INSERT … ON DUPLICATE KEY UPDATE
REPLACE INTO、INSERT IGNORE 、INSERT INTO VALUES(),(),()
UPDATE … WHERE ID IN(10,20,50,…)

八、合理的使用分頁

限制分頁展現的頁數
只能點擊上一頁、下一頁
採用延遲關聯

如何正確的使用分頁？

假若有相似下面分頁語句：SELECT * FROM table ORDER BY id LIMIT 10000, 10

因爲MySQL裏對LIMIT OFFSET的處理方式是取出OFFSET+LIMIT的全部數據，而後去掉OFFSET，返回底部的LIMIT。因此，在OFFSET數值較大時，MySQL的查詢性能會很是低。可使用id > n 的方式進行解決：

使用id > n 的方式有侷限性，對於id不連續的問題，能夠經過翻頁的時候同時傳入最後一個id方式來解決。

1

2

3

4

5

6

7

//輸出時，找出當前結果集中的最大最小id

//下一頁

http://example.com/page.php?last=100

select * from table where id<100 order by id desc limit 10

//上一頁

http://example.com/page.php?first=110

select * from table where id>110 order by id desc limit 10

這種方式比較大的缺點是，若是在瀏覽中有插入/刪除操做，翻頁不會更新，而總頁數可能仍然是根據新的count(*) 來計算，最終可能會產生某些記錄訪問不到。爲了修補這個問題，能夠繼續引入當前頁碼以及在上次翻頁之後是否有插入/刪除等影響總記錄數的操做並進行緩存

其餘變種方式：

1

select * from table where id >= (select id from table order by id limit #offset#, 1)

九、拒絕大SQL，拆分紅小SQL

充分利用QUERY CACHE
充分利用多核CPU

十、使用in代替or，in的值不超過1000個

十一、禁止使用order by rand()

十二、使用EXPLAIN診斷，避免生成臨時表

EXPLAIN語句（在MySQL客戶端中執行）能夠得到MySQL如何執行SELECT語句的信息。經過對SELECT語句執行EXPLAIN，能夠知曉MySQL執行該SELECT語句時是否使用了索引、全表掃描、臨時表、排序等信息。儘可能避免MySQL進行全表掃描、使用臨時表、排序等。詳見官方文檔。

1三、用union all而不是union

union all與 union有什麼區別？

union和union all關鍵字都是將兩個結果集合併爲一個，但這二者從使用和效率上來講都有所不一樣。

union在進行表連接後會篩選掉重複的記錄，因此在表連接後會對所產生的結果集進行排序運算，刪除重複的記錄再返回結果。如：

1

2

3

select * from test_union1

union

select * from test_union2

這個SQL在運行時先取出兩個表的結果，再用排序空間進行排序刪除重複的記錄，最後返回結果集，若是表數據量大的話可能會致使用磁盤進行排序。

而union all只是簡單的將兩個結果合併後就返回。這樣，若是返回的兩個結果集中有重複的數據，那麼返回的結果集就會包含重複的數據了。

從效率上說，union all要比union快不少，因此，若是能夠確認合併的兩個結果集中不包含重複的數據的話，那麼就使用union all，以下：

1

2

3

select * from test_union1

union all

select * from test_union2