規則1:通常狀況能夠選擇MyISAM存儲引擎,若是須要事務支持必須使用InnoDB存儲引擎。mysql
注意:MyISAM存儲引擎 B-tree索引有一個很大的限制:參與一個索引的全部字段的長度之和不能超過1000字節。另外MyISAM數據和索引是分開,而InnoDB的數據存儲是按聚簇(cluster)索引有序排列的,主鍵是默認的聚簇(cluster)索引,所以MyISAM雖然在通常狀況下,查詢性能比InnoDB高,但InnoDB的以主鍵爲條件的查詢性能是很是高的。spring
規則2:命名規則。sql
規則3:數據庫字段類型定義數據庫
規則4:業務邏輯執行過程必須讀到的表中必需要有初始的值。避免業務讀出爲負或無窮大的值致使程序失敗緩存
規則5:並不須要必定遵照範式理論,適度的冗餘,讓Query儘可能減小Join性能優化
規則6:訪問頻率較低的大字段拆分出數據表。有些大字段佔用空間多,訪問頻率較其餘字段明顯要少不少,這種狀況進行拆分,頻繁的查詢中就不須要讀取大字段,形成IO資源的浪費。微信
規則7:大表能夠考慮水平拆分。大表影響查詢效率,根據業務特性有不少拆分方式,像根據時間遞增的數據,能夠根據時間來分。以id劃分的數據,可根據id%數據庫個數的方式來拆分。架構
規則8:業務須要的相關索引是根據實際的設計所構造sql語句的where條件來肯定的,業務不須要的不要建索引,不容許在聯合索引(或主鍵)中存在多於的字段。特別是該字段根本不會在條件語句中出現。併發
規則9:惟一肯定一條記錄的一個字段或多個字段要創建主鍵或者惟一索引,不能惟一肯定一條記錄,爲了提升查詢效率建普通索引分佈式
規則10:業務使用的表,有些記錄數不多,甚至只有一條記錄,爲了約束的須要,也要創建索引或者設置主鍵。
規則11:對於取值不能重複,常常做爲查詢條件的字段,應該建惟一索引(主鍵默認惟一索引),而且將查詢條件中該字段的條件置於第一個位置。沒有必要再創建與該字段有關的聯合索引。
規則12:對於常常查詢的字段,其值不惟一,也應該考慮創建普通索引,查詢語句中該字段條件置於第一個位置,對聯合索引處理的方法一樣。
規則13:業務經過不惟一索引訪問數據時,須要考慮經過該索引值返回的記錄稠密度,原則上可能的稠密度最大不能高於0.2,若是稠密度太大,則不合適創建索引了。
當經過這個索引查找獲得的數據量佔到表內全部數據的20%以上時,則須要考慮創建該索引的代價,同時因爲索引掃描產生的都是隨機I/O,生其效率比全表順序掃描的順序I/O低不少。數據庫系統優化query的時候有可能不會用到這個索引。
規則14:須要聯合索引(或聯合主鍵)的數據庫要注意索引的順序。SQL語句中的匹配條件也要跟索引的順序保持一致。
注意:索引的順勢不正確也可能致使嚴重的後果。
規則15:表中的多個字段查詢做爲查詢條件,不含有其餘索引,而且字段聯合值不重複,能夠在這多個字段上建惟一的聯合索引,假設索引字段爲 (a1,a2,...an),則查詢條件(a1 op val1,a2 op val2,...am op valm)m<=n,能夠用到索引,查詢條件中字段的位置與索引中的字段位置是一致的。
規則16:聯合索引的創建原則(如下均假設在數據庫表的字段a,b,c上創建聯合索引(a,b,c))
規則17:重要業務訪問數據表時。但不能經過索引訪問數據時,應該確保順序訪問的記錄數目是有限的,原則上不得多於10.
規則18:合理構造Query語句
Mysql在併發這塊作得並非太好,當併發量過高的時候,總體性能會急劇降低,這主要與Mysql 內部資源的爭用鎖定控制有關,MyIsam用表鎖,InnoDB好一些用行鎖。
規則19:應用系統的優化
一、 合理使用cache,對於變化較少的部分活躍數據經過應用層的cache緩存到內存中,對性能的提高是成數量級的。
二、 對重複執行相同的query進行合併,減小IO次數。
三、 事務相關性最小原則
在此我向你們推薦一個架構學習交流羣。交流學習羣號:478030634 裏面會分享一些資深架構師錄製的視頻錄像:有Spring,MyBatis,Netty源碼分析,高併發、高性能、分佈式、微服務架構的原理,JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源,目前受益良多
注:關注做者微信公衆號,瞭解更多分佈式架構、微服務、netty、MySQL、spring、性能優化、等知識點。公衆號:《Java爛豬皮》