很多人都認為效能是在通過編寫**（程式**或者是資料庫**）的過程中優化出來的，其實這是乙個非常大的誤區。真正影響效能最大的部分是在設計中就已經產生了的，後期的優化很多時候所能夠帶來的改善都只是在解決前妻設計所遺留下來的一些問題而已，而且能夠解決的問題通常也比較有限。本章將就如何在 mysql 資料庫 schema 設計的時候保證盡可能的高效，盡可能減少後期的煩惱。
對於基於效能的資料庫 schema 設計，我們並不能完全以規範化正規化理論來作為唯一的指導。在設計過程中，應該從實際需求出發，以效能提公升為根本目標來展開設計工作，很多時候為了盡可能提高效能，我們也不得不做反正規化設計。
1、適度冗餘 - 讓 query 盡兩減少 join
mysql 的優化器雖然號稱使用了新一代的優化器技術實現的非常優秀，但是由於目前 mysql 所收集的資料統計資訊還不是特別的多，所以起表現並不是特別的讓人滿意，不少時候對各表的訪問順序選擇的並不合適，造成複雜 query 的整體執行效率低下。所以，為了讓我們的 query 執行計畫盡可能的最優化，最直接有效的方式就是儘量減少 join，而要減少 join，我們就不可避免的需要通過表字段的冗餘來實現。
2、大字段垂直分拆 - summary 表優化
那到底什麼樣的字段適合於從表中拆分出去呢？
a、首要肯定是大字段。為什麼？原因很簡單，就是因為他的大。
b、其次是和表中其他字段相比訪問頻率明顯要少很多。如果我們已經確定有大字
段需要分拆出主表的時候，對於其他的字段，只要滿足訪問頻率和大字段一樣相對於表中其他欄位要低很多的都可以和大字段同時分拆出來。實際上，在有些時候，我們甚至都不一定非要大字段才能進行垂直分拆。在有些場景下，有的表中大部分字段平時都很少訪問，而其中的某幾個字段卻是訪問頻率非常高。對於這種表，也非常適合通過垂直分拆來達到優化效能的目的。
3、大表水平分拆 - 基於型別的分拆優化
4、統計表 - 準實時優化
什麼型別的統計資訊適合通過準實時統計表來優化實現？
首先，統計資訊的準確性要求並不是特別的嚴格；
其次，統計資訊對時間並不是太敏感；
再次，統計資訊的訪問非常頻繁，重複執行較多；
最後，參與統計資料量較大；
優化資料型別提高效能的主要原理在於以下幾個方面：
1. 通過選用更「小」的資料型別減少儲存空間，使查詢相同資料需要的 io 資源降低；
2. 通過合適的資料型別加速資料的比較；
規範的命名本身並不會對效能有任何影響，在這裡單獨列出一節來講，主要是因為這是乙個不太被人重視，但是對後期的資料庫維護影響非常大的內容。
一般來說，我個人建議需要注意以下一些方面：
1、 資料庫和表名應盡可能和所服務的業務模組名一致；
2、 服務於同一子模組的一類表盡量以子模組名（或部分單詞）為字首或字尾；
3、 表名應盡量包含與所存放資料相對應的單詞；
4、 欄位名稱也盡量保持和實際資料相對應
5、 索引名稱盡量包含所有的索引鍵欄位名或者縮寫，且各欄位名在索引名中的順序應與索引鍵在索引中的索引順序一致，且盡量包含乙個類似於 idx 或者 ind 之類的字首或者字尾，以表名其物件型別是索引，同時還可以包含該索引所屬表的名稱；這樣做最大的好處在於 dba 在維護過程中能夠非常直接清晰的通過索引名稱就了解到該索引大部分的資訊。
6、 約束等其他物件也應該盡可能包含所屬表或其他物件的名稱，以表名各自關係。
資料庫 schema含義
資料庫schema有兩種含義，一種是概念上的schema，指的是一組ddl語句集，該語句集完整地描述了資料庫的結構。還有一種是物理上的schema，指的是資料庫中的乙個名字空間，它包含一組表 檢視和儲存過程等命名物件。物理schema可以通過標準sql語句來建立 更新和修改。例如以下sql語句建立了...
資料庫中schema
在學習sql的過程中，會遇到乙個讓你迷糊的schema的概念。實際上，schema就是資料庫物件的集合，這個集合包含了各種物件如 表 檢視 儲存過程 索引等。為了區分不同的集合，就需要給不同的集合起不同的名字，預設情況下乙個使用者對應乙個集合，使用者的schema名等於使用者名稱，並作為該使用者預設...
資料庫Schema概念
在學習sql的過程中，會遇到乙個讓你迷糊的schema的概念。實際上，schema就是資料庫物件的集合，這個集合包含了各種物件如 表 檢視 儲存過程 索引等。為了區分不同的集合，就需要給不同的集合起不同的名字，預設情況下乙個使用者對應乙個集合，使用者的schema名等於使用者名稱，並作為該使用者預設...