MySql 資料庫 Schema 設計的效能最佳化：規範的物件命名

規範的命名本身並不會對效能有任何影響，在這裡單獨列出一節來講，主要是因為這是一個不太被人重視，但是對後期的資料庫維護影響非常大的內容。 就像程式語言各自的一些 不成文編碼基本規範一樣，雖然在最初使用的時候並看不錯太多的利益，反而會被人認為是一種束縛，但是當每一個人在接手維護一段編寫很不規範的程式碼的時候，我估計大部分人都會非常鬱悶，甚至在心裡暗罵當初的編寫者。其實任何系統都一樣，沒有任何規範可循，完全一個天馬行空的作風，只會給後人（甚至可能是自己）留下一個讓人摸不著頭腦的爛攤子，難以維護。

對於資料庫物件的命名規範其實可以很簡單，而且業界也並不存在一個嚴格的統一規定，只需要在一個公司內足夠統一基本就可以了。

一般來說，我個人建議需要注意以下一些方面：

1. 資料庫和表名應儘可能和所服務的業務模組名一致；
   這樣，在  DBA 維護相關資料庫物件的時候，新開發人員程式開發過程中，相關技術（或非技術）人員整理業務邏輯和資料關係的時候，都能夠非常容易理解其中的關係。

2. 服務於同一子模組的一類表儘量以子模組名（或部分單詞）為字首或字尾；
   對同類功能的表增加字首或者字尾，也是讓檢視使用該表的各類人員能夠很快的根據相關物件的名稱就聯想到相應的功能，以及相關業務。不論是從維護角度，還是從使用角度來看都會帶來非常大的便利性。

3. 表名應儘量包含與所存放資料相對應的單詞；
   這對於新員工來說尤其重要，要想盡快的熟悉資料，儘快瞭解相關業務，快速的定位資料庫中各表對應的資料意義是非常有幫助的。

4. 欄位名稱也儘量保持和實際資料相對應；
   這一點的意義我想各位讀者朋友應該都非常的清楚，每個表都會有很多的欄位對應資料的各種不同屬性，要搞清楚各自代表的含義，除了完整規範的說明文件之外，命名清晰合理的欄位名也是一個有用的補充，而且更為直接。

5. 索引名稱儘量包含所有的索引鍵欄位名或者縮寫，且各欄位名在索引名中的順序應與索引鍵在索引中的索引順序一致，且儘量包含一個類似於 idx 或者 ind 之類的字首或者字尾，以表名其物件型別是索引，同時還可以包含該索引所屬表的名稱；
   這樣做最大的好處在於  DBA 在維護過程中能夠非常直接清晰的透過索引名稱就瞭解到該索引大部分的資訊。

6. 約束等其他物件也應該儘可能包含所屬表或其他物件的名稱，以表名各自關係。

上面列出的只是一個比較初略的規範建議，各位讀者朋友完全可以根據各自公司的習慣，制定自己的命名規範，只要適用，就可以了。規範不在多，而在實用。而且一旦制定的規範，就必須嚴格的按照規範執行，否則就變成了個花架子沒有任何實際的意義了。