原創：小姐姐味道（微信公眾號ID：xjjdog），歡迎分享，轉載請保留出處。
晚上，我被叫進寬大的辦公室，總監正在煮茶。高壓鍋煮著長嘴茶壺，水蒸氣繚繞。領導舉手之間，淡黃茶水奔湧而出，倒立而下澆上茶葉，漏出兩杯茶水。
「喝茶？」領導推給我一杯，然後自己抿了一口。沉默良久，把顯示器轉到我這邊：「最近資料庫表出現了些有意思的東西，你來看看」。
我探著腦袋一瞧，心涼了半截。
時隔五年，又在項目裡見到哥哥表和妹妹欄位，著實讓我坐立不安。所謂哥哥表，就是名稱叫做gg的資料庫表，意為公共；所謂妹妹欄位，就是名稱叫做mm的表子段，意為密碼。比起shit mountain來，這些命名更讓人浮想聯翩，實為不規範之典範。
這麼魔幻的事情，不止一次出現，任何領導都會坐不住。可惜的是，一次次的會議，專項討論某一個SQL禁止條例，到最後還是大開方便之門，過往的規範承諾皆拋之腦外。
資料庫命名規範是最基礎的規範，連這個都沒做好，證明監管工作確實出現了紕漏。我趕緊掏出自己的手機，翻到xjjdog的文章，打算把資料庫要注意的點，給領導匯報一下。
也順便向大家匯報。
我把規範分成了統一的規範、索引規範、SQL規範、命名規範、安全規範、性能小Case等6個部分。
請聽我慢慢道來。
1. 統一的規範首先，我們來一些通用的規範。這裡有很多是經驗值，如果你的資料庫所在的宿主機硬體，並不是十分的牛X，可以考慮再降低一下標準。
存儲引擎： 請統一使用innodb存儲引擎，特殊的資料庫引擎必須通過DBA的評審。
字符集：統一使用utf8字符集。這個要從應用程式、伺服器、資料庫的表、欄位等全部統一起來。注意：MySQL中的utf8mb4字符集，才是真正的utf8，請用這個。
作用範圍：不要在MySQL存儲大對象，比如圖片、音樂等；不要用MySQL做Gis運算、全文檢索；不使用存儲過程、觸發器、函數、外鍵，避免破壞資料庫的性能和擴展性。
使用上限：
單張表中索引數量不超過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欄位，避免並發操作造成的不一致情況。
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類型；使用更小的數據類型，能用tinyint的就不用smallint，能用timestamp的就不用datetime類型；不能使用tinyblob、mediumblob、blob和longblob類型欄位，對於表存在大欄位類型，應當考慮單獨拆分。
OLTP資料庫絕對要避免大事務和資料庫端運算，可以考慮使用NoSQL或者大數據計算平臺。
End可以看到，我們規範裡，有些禁止的東西，其實最後還是用了。比如分區表、大欄位存儲、GIS操作。但這是和規範不衝突的。
規範，只定義了一些常見的可能會引起嚴重後果的操作禁止，然後將風險的事情，交給專業的人去做，並評估、控制風險點的規模。
規範定了，要執行才行。不論是人工的review，還是工具的檢測。如此，系統才能健康成長，程式設計師才能不加班，領導才能開上保時捷。
這時候，我匯報完畢，抬頭向領導望去。他的頭倚在真皮座椅後背上，已經沉沉的的睡了過去。我把外套輕輕脫下來，披在他身上，這才捧過自己的茶杯，咕咚一口喝了下去。雖然茶已經涼了，但醇香一直在嘴中繚繞。
作者簡介：小姐姐味道 (xjjdog)，一個不允許程式設計師走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高並發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。