[[374227]]

本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗 。轉載本文請聯系小姐姐味道公眾號。  

晚上，我被叫進寬大的辦公室，總監正在煮茶。高壓鍋煮著長嘴茶壺，水蒸氣繚繞。領導舉手之間，淡黃茶水奔涌而出，倒立而下澆上茶葉，漏出兩杯茶水。

“喝茶?”領導推給我一杯，然后自己抿了一口。沉默良久，把顯示器轉到我這邊：“最近數據庫表出現了些有意思的東西，你來看看”。

我探著腦袋一瞧，心涼了半截。

時隔五年，又在項目里見到哥哥表和妹妹字段，著實讓我坐立不安。所謂哥哥表，就是名稱叫做gg的數據庫表，意為公共;所謂妹妹字段，就是名稱叫做mm的表子段，意為密碼。比起shit mountain來，這些命名更讓人浮想聯翩，實為不規范之典范。

這么魔幻的事情，不止一次出現，任何領導都會坐不住。可惜的是，一次次的會議，專項討論某一個SQL禁止條例，到最后還是大開方便之門，過往的規范承諾皆拋之腦外。

數據庫命名規范是最基礎的規范，連這個都沒做好，證明監管工作確實出現了紕漏。我趕緊掏出自己的手機，翻到xjjdog的文章，打算把數據庫要注意的點，給領導匯報一下。

也順便向大家匯報。

我把規范分成了統一的規范、索引規范、SQL規范、命名規范、安全規范、性能小Case等6個部分。

請聽我慢慢道來。

1. 統一的規范

首先，我們來一些通用的規范。這里有很多是經驗值，如果你的數據庫所在的宿主機硬件，并不是十分的牛X，可以考慮再降低一下標準。

存儲引擎： 請統一使用innodb存儲引擎，特殊的數據庫引擎必須通過DBA的評審。

字符集：統一使用utf8字符集。這個要從應用程序、服務器、數據庫的表、字段等全部統一起來。注意：MySQL中的utf8mb4字符集，才是真正的utf8，請用這個。

作用范圍：不要在MySQL存儲大對象，比如圖片、音樂等;不要用MySQL做Gis運算、全文檢索;不使用存儲過程、觸發器、函數、外鍵，避免破壞數據庫的性能和擴展性。

使用上限：

• 每個MySQL實例，數據庫不要超過50個;
• 單數據庫容量，不要超過500GB，否則分庫;
• 單表記錄數量，不要超過5000W，否則分表;
• 單表子段數量，不要超過30個，否則拆表;
• 單張表中索引數量不超過5個，單個索引中的字段數不超過5個;
• varchar字段最大值不超過1024;注意：VARCHAR(N)中的N表示字符數而非字節數

2. 索引規范

索引是數據庫中非常重要的結構，可以加速數據的檢索。但索引是要占用大量空間的，如果你的數據表里面沒幾條記錄，就不必創建索引。比如2000條以下。

選擇性很小的字段(低基數列)，不要加索引。比如一些state，type，布爾判斷等。因為加了也沒用。

盡量讓索引的內容盡量的短!比較長的子段，要使用前綴索引。比如：title varchar (64) ，可以創建前綴索引 idx_title (title(16))。

合理利用索引的最左原則，合并相似的索引。比如 (a) (ab) (abc)三種索引需求，我們只需要創建abc這一個索引就ok了。

避免在索引列做計算(這將造成索引失效)，比如 data_format(created_date)，substring(short_name,0,6) = 'xjjdog'。

不能使用%前綴模糊查詢，因為無法使用索引，例如：WHERE name LIKE '%味道'。

不能使用數據庫端做全文檢索操作。雖然它支持，也不要這么做。

索引的命名要有章可循：idx_前綴表明是普通索引，而 uk_前綴表明的是唯一索引。

3. SQL規范

建議在每個表中，添加下面三個字段。其實，SpringBoot JPA，也建議你添加上這三個字段。根據時間字段，除了審計，還能夠做一些非常nice的遷移操作;version字段是高并發下的樂觀鎖實現，UPDATE語句可以結合version字段，避免并發操作造成的不一致情況。

• created：記錄創建時間，時間類型
• modified：記錄修改時間，時間類型
• version：“樂觀鎖”的版本標記，long型，默認為0

大多數字段應該定義成not null的，并分配默認值，但是不要default null，因為數據庫無法索引null值。

復雜的SQL查詢語句，是絕對要避免的。我們所說的，就是慢查詢。慢查詢會占用大量資源，并阻塞線程，應該見諒將大SQL拆分成多條簡單的SQL，減少數據的鎖定時間。

另外，不要在不同數據類型的字段上進行比較，避免字段類型轉換造成性能損失，這就要求我們在SQL語句中傳入的參數類型，和數據庫中所定義的類型是相同的。

禁止使用select *進行輸出，應該選擇具體的字段進行輸出。除了避免無用的字段造成傳輸上的性能損耗，還能在一定程度上避免敏感信息的泄漏。

SQL中避免出現now()、rand()、sysdate()、current_user()等不確定結果的函數。

禁止使用order by rand()。

插入語句，不要直接使用 nsert into table values()，而應該加入具體的字段，否則無法適應數據庫變更情況。在做批量插入時，一次性操作100-200條就可以，沒必要把batch數量設置成上千上萬。

禁止非框架類業務代碼，直接調用set sql_mode或者set tx_isolation，禁止使用SELECT … FOR UPDAT，優先采用樂觀鎖實現。

多表關聯不要超過3個，盡量拆分成簡單的SQL處理。

大多數開發人員會在需要時寫UNION，這往往會導致執行一個排序來消除重復。應該盡量使用UNION ALL來代替UNION。

注意OR語句的一些改善情況。比如WHERE id=1 OR id=2可以 改寫為WHERE id IN(1,2)。在不同的字段，可以將OR改寫為UNION ALL。

4. 命名規范

數據庫表和字段的命名，不要使用駝峰命名方式。比如，不能叫saleOrder，而應該叫做sale_order。因為大多數數據庫，都不區分大小寫，下劃線命名會更安全。

這些命名，只能使用英文小寫字母、數字和下劃線，長度不超過17個字符。

命名應該有確切的含義。和代碼規范一樣，不允許使用a，b等無意義的字符串。不允許中文拼音縮寫、中英文混用等。

嚴禁出現哥哥表和妹妹字段。

5. 安全安全安全圖片

(1) 服務器隔離 如果你的公司有多個環境，比如dev環境，測試環境等，就要做好相應的隔離。比如，不允許在線上環境直接進行開發和測試、禁止在線上做數據庫壓?力測試。這是非常重要的，避免了無謂的數據錯亂。如果條件允許，甚至可以做物理隔離，用不同的IP段進行區分。不長腦子的程序員有很多，你永遠不知道他們連的是哪個環境的數據庫。

(2)賬戶的權限 永遠不要在生產上，讓root賬號遠程可連。對不同的應用，應該分配不同的database，并建立相互隔離的賬號。

賬號默認開啟select/insert/update/delete/execute的權限就可以。create都不能放開，用根本上杜絕程序員們刪庫跑路的機會。

針對安全級別高的應用，應分配讀寫賬號。讀賬號去掉各種更新權限，只能做一些sql查詢。賬號命名方式上，可以加入_w或者_r后綴，表明它們的意圖。

對于SQL的傳入參數(數字，字符和混用)必須進行合法性檢查，防止SQL注入。業務應該提前準備好風險SQL語句，進行集中審核，負責后果自負。

6. 性能小case

如有自增字段，請使用無符號型(unsigned)int或bigint 。優先使用更小的數據類型，比如：

數字用tinyint、smallint、mediumint、int、bigint類型;

日期用date、datetime類型;

時間用timestamp、int類型;

不使用char、varchar存儲日期和時間;

使用更小的數據類型，能用tinyint的就不用smallint，能用timestamp的就不用datetime類型;

不能使用tinyblob、mediumblob、blob和longblob類型字段，對于表存在大字段類型，應當考慮單獨拆分。

OLTP數據庫絕對要避免大事務和數據庫端運算，可以考慮使用NoSQL或者大數據計算平臺。

End

可以看到，我們規范里，有些禁止的東西，其實最后還是用了。比如分區表、大字段存儲、GIS操作。但這是和規范不沖突的。

規范，只定義了一些常見的可能會引起嚴重后果的操作禁止，然后將風險的事情，交給專業的人去做，并評估、控制風險點的規模。

規范定了，要執行才行。不論是人工的review，還是工具的檢測。如此，系統才能健康成長，程序員才能不加班，領導才能開上保時捷。

這時候，我匯報完畢，抬頭向領導望去。他的頭倚在真皮座椅后背上，已經沉沉的的睡了過去。我把外套輕輕脫下來，披在他身上，這才捧過自己的茶杯，咕咚一口喝了下去。雖然茶已經涼了，但醇香一直在嘴中繚繞。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。