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

本文前提

高併發環境

規則要點

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，極大影響資料庫效能

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