本文大部分轉至沈劍老師，加上自己的一些見解。

本文前提

高並發環境

規則要點

1） 數據庫字符集使用utf8mb4

無亂碼風險、萬國碼

2）禁止使用存儲過程、視圖、觸發器、Event

高並發大數據的互聯網業務，架構設計思路是“解放數據庫CPU，將計算轉移到服務層”，並發量大的情況下，這些功能很可能將數據庫拖死，業務邏輯放到服務層具備更好的擴展性，能夠輕易實現“增機器就加性能”。數據庫擅長存儲與索引，CPU計算還是上移吧

3）禁止存儲大文件或者大照片

使用路程存儲。建個存儲文件的服務器，或者用雲端Azure的blob文件存儲

4）表名必須英文

5）單實例表數目必須小於500

6）單表列數目必須小於30

7）表必須有主鍵，建議不要用自增長主鍵

無主鍵的表刪除，在row模式的主從架構，會導致備庫夯住

不用自增長主鍵是因為當插入數據時，數據庫首先會查詢最大的索引值，然後再進行插入操作。所以，使用較短的string類型或者guid直接插入。

8）禁止使用外鍵，如果有外鍵完整性約束，需要應用程序控制

外鍵會導致表與表之間耦合，update與delete操作都會涉及相關聯的表，十分影響sql 的性能，甚至會造成死鎖。高並發情況下容易造成數據庫性能，大數據高並發業務場景數據庫使用以性能優先

9）須把字段定義為NOT NULL並且提供默認值

null的列使索引/索引統計/值比較都更加復雜，對MySQL（其他數據庫差不多）來說更難優化

null 這種類型MySQL內部需要進行特殊處理，增加數據庫處理記錄的復雜性；同等條件下，表中有較多空字段的時候，數據庫的處理性能會降低很多

null值需要更多的存儲空，無論是表還是索引中每行中的null的列都需要額外的空間來標識

對null 的處理時候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in這些操作符號。如：where name!=’alunchen’，如果存在name為null值的記錄，查詢結果就不會包含name為null值的記錄

10）禁止使用TEXT、BLOB大類型

會浪費更多的磁盤和內存空間，非必要的大量的大字段查詢會淘汰掉熱數據，導致內存命中率急劇降低，影響數據庫性能

11）單表索引個數，建議控制在5個以內

字段超過5個時，實際已經起不到有效過濾數據的作用了

12）禁止在更新十分頻繁、區分度不高的屬性上建立索引

更新會變更B+樹，更新頻繁的字段建立索引會大大降低數據庫性能

“性別”這種區分度不大的屬性，建立索引是沒有什麽意義的，不能有效過濾數據，性能與全表掃描類似

13）建立組合索引，必須把區分度高的字段放在前面

能夠更加有效的過濾數據

14）禁止使用SELECT *

消耗數據庫IO性能

不能有效的利用覆蓋索引

15）禁止使用INSERT INTO tableA VALUES(xxx)，必須顯示指定插入的列屬性

容易在增加或者刪除字段後出現程序BUG

16）禁止使用屬性隱式轉換

SELECT uid FROM t_user WHERE phone=13800138000 會導致全表掃描，而不能命中phone索引。因為phone是字符串類型，

SQL語句帶入的是整形，故不會命中索引，加個引號就好了：

SELECT uid FROM t_user WHERE phone=’13800138000’

17）禁止在WHERE條件的屬性上使用函數或者表達式

SELECT uid FROM t_user WHERE from_unixtime(day)>=‘2017-02-15‘ 會導致全表掃描

正確的寫法是：SELECT uid FROM t_user WHERE day>= unix_timestamp(‘2017-02-15 00:00:00‘)

18）禁止負向查詢，以及%開頭的模糊查詢

負向查詢條件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，會導致全表掃描

%開頭的模糊查詢，會導致全表掃描。

一般來說，WHERE過濾條件不會只帶這麽一個“負向查詢條件”，還會有其他過濾條件，舉個例子：查詢我已完成訂單之外的訂單（好拗口）：

SELECT oid FROM t_order WHERE uid=123 AND status != 1;

訂單表5000w數據，但uid=123就會迅速的將數據量過濾到很少的級別（uid建立了索引），此時再接上一個負向的查詢條件就無所謂了，掃描的行數本身就會很少。

但如果要查詢所有已完成訂單之外的訂單：

SELECT oid FROM t_order WHERE status != 1;

這就掛了，立馬CPU100%，status索引會失效，負向查詢導致全表掃描。

19）禁止大表使用JOIN查詢，禁止大表使用子查詢

會產生臨時表，消耗較多內存與CPU，極大影響數據庫性能

可以關註本人的公眾號，多年經驗的原創文章共享給大家。

數據庫 之 高並發環境下的規則