晚上，我被叫進寬大的辦公室，總監正在煮茶。高壓鍋煮著長嘴茶壺，水蒸氣繚繞。領導舉手之間，淡黃茶水奔湧而出，倒立而下澆上茶葉，漏出兩杯茶水。
「喝茶？」領導推給我一杯，然後自己抿了一口。沉默良久，把顯示器轉到我這邊：「最近資料庫表出現了些有意思的東西，你來看看」。
我探著腦袋一瞧，心涼了半截。
時隔五年，又在專案裡見到哥哥表和妹妹字段，著實讓我坐立不安。所謂哥哥表，就是名稱叫做gg的資料庫表，意為公共；所謂妹妹字段，就是名稱叫做mm的錶子段，意為密碼。比起**** mountain來，這些命名更讓人浮想聯翩，實為不規範之典範。
image
這麼魔幻的事情，不止一次出現，任何領導都會坐不住。可惜的是，一次次的會議，專項討論某乙個sql禁止條例，到最後還是大開方便之門，過往的規範承諾皆拋之腦外。
資料庫命名規範是最基礎的規範，連這個都沒做好，證明監管工作確實出現了紕漏。我趕緊掏出自己的手機，翻到xjjdog的文章，打算把資料庫要注意的的點，給領導匯報一下。
也順便向大家匯報。
我把規範分成了統一的規範、索引規範、sql規範、命名規範、安全規範、效能小case等6個部分。
請聽我慢慢道來。
首先，我們來一些通用的規範。這裡有很多是經驗值，如果你的資料庫所在的宿主機硬體，並不是十分的牛x，可以考慮再降低一下標準。
儲存引擎：請統一使用innodb儲存引擎，特殊的資料庫引擎必須通過dba的評審。
字符集： 統一使用utf8字符集。這個要從應用程式、伺服器、資料庫的表、欄位等全部統一起來。注意：mysql中的utf8mb4字符集，才是真正的utf8，請用這個。
作用範圍：不要在mysql儲存大物件，比如、**等；不要用mysql做gis運算、全文檢索；不使用儲存過程、觸發器、函式、外來鍵，避免破壞資料庫的效能和擴充套件性。
使用上限：
索引是資料庫中非常重要的結構，可以加速資料的檢索。但索引是要占用大量空間的，如果你的資料表裡面沒幾條記錄，就不必建立索引。比如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_字首表明的是唯一索引。
建議在每個表中，新增下面三個字段。其實，springboot jpa，也建議你新增上這三個字段。根據時間字段，除了審計，還能夠做一些非常nice的遷移操作；version欄位是高併發下的樂觀鎖實現，update語句可以結合version欄位，避免併發操作造成的不一致情況。
大多數字段應該定義成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。
資料庫表和字段的命名，不要使用駝峰命名方式。比如，不能叫saleorder，而應該叫做sale_order。因為大多數資料庫，都不區分大小寫，下劃線命名會更安全。
這些命名，只能使用英文小寫字母、數字和下劃線，長度不超過17個字元。
命名應該有確切的含義。和**規範一樣，不允許使用a，b等無意義的字串。不允許中文拼音縮寫、中英文混用等。
嚴禁出現哥哥表和妹妹字段。
（2）賬戶的許可權 永遠不要在生產上，讓root賬號遠端可連。對不同的應用，應該分配不同的database，並建立相互隔離的賬號。
賬號預設開啟select/insert/update/delete/execute的許可權就可以。create都不能放開，用根本上杜絕程式設計師們刪庫跑路的機會。
針對安全級別高的應用，應分配讀寫賬號。讀賬號去掉各種更新許可權，只能做一些sql查詢。賬號命名方式上，可以加入_w或者_r字尾，表明它們的意圖。
對於sql的傳入引數（數字，字元和混用）必須進行合法性檢查，防止sql注入。業務應該提前準備好風險sql語句，進行集中審核，負責後果自負。
如有自增欄位，請使用無符號型（unsigned）int或bigint 。優先使用更小的資料型別，比如：
不能使用tinyblob、mediumblob、blob和longblob型別字段，對於表存在大字段型別，應當考慮單獨拆分。
oltp資料庫絕對要避免大事務和資料庫端運算，可以考慮使用nosql或者大資料計算平台。
可以看到，我們規範裡，有些禁止的東西，其實最後還是用了。比如分割槽表、大字段儲存、gis操作。但這是和規範不衝突的。
規範，只定義了一些常見的可能會引起嚴重後果的操作禁止，然後將風險的事情，交給專業的人去做，並評估、控制風險點的規模。
規範定了，要執行才行。不論是人工的review，還是工具的檢測。如此，系統才能健康成長，程式設計師才能不加班，領導才能開上保時捷。
這時候，我匯報完畢，抬頭向領導望去。他的頭倚在真皮座椅後背上，已經沉沉的的睡了過去。我把外套輕輕脫下來，披在他身上，這才捧過自己的茶杯，咕咚一口喝了下去。雖然茶已經涼了，但醇香一直在嘴中繚繞。
學習方法 有乙個成績很好的哥哥是什麼體驗？
我哥第一次認真的教我。不同於以前的敷衍，他幫我從書上畫出重點，自己出題目給我做，他要求我反覆的去做他畫的重點題目，不停的做，反覆的做，全神貫注的去體會，讓大腦自己去熟悉這個解題過程，而不是單純的去記憶解題方法，更不是記住答案，必須要用自己的思維去感受，去揣摩一步步解開這個邏輯命題的步驟，體會這種感覺...
MYSQL中InnoDB是什麼
innodb的特色在於支援併發與表間引用 mysql支援多種儲存引擎，使用者可以方便的選用不同的儲存引擎來支援自己的應用，每種不同的儲存引擎都有其自己的特性 innodb是其中的一種儲存引擎，它的特性是支援事務，並且採用多版本併發控制的方式來提高併發度主要是事務表，當乙個事務全部完成，才會執行upd...
mysql 約束是什麼 mysql中約束有什麼用
什麼叫做約束？約束，就是要求資料需要滿足什麼條件的一種 規定 主要有如下幾種約束 主鍵約束 形式 primary key 欄位名 含義 作用 使該設定欄位的值可以用於 唯一確定一行資料 其實就是 主鍵 的意思。唯一約束 形式 unique key 欄位名 含義 作用 使該設定欄位的值具有 唯一性 自...