https://www.qcloud.com/community/article/164816001481011831?fromSource=gwzcw.82729.82729.82729 規則1：一般情況可以選擇MyISAM存儲引擎，如果需要事務支持必須使用InnoDB存儲引擎。 注意：MyISAM存儲引擎 B-tree索引有一個很大的限制：參與一個索引的所有字段的長度之和不能超過1000字節。另外MyISAM數據和索引是分開，而InnoDB的數據存儲是按聚簇(cluster)索引有序排列的，主鍵是默認的聚簇(cluster)索引，因此MyISAM雖然在一般情況下，查詢性能比InnoDB高，但InnoDB的以主鍵為條件的查詢性能是非常高的。 規則2：命名規則。 1. 數據庫和表名應盡可能和所服務的業務模塊名一致 2. 服務與同一個子模塊的一類表應盡量以子模塊名(或部分單詞)為前綴或后綴 3. 表名應盡量包含與所存放數據對應的單詞 4. 字段名稱也應盡量保持和實際數據相對應 5. 聯合索引名稱應盡量包含所有索引鍵字段名或縮寫，且各字段名在索引名中的順序應與索引鍵在索引中的索引順序一致，并盡量包含一個類似idx的前綴或后綴，以表明期對象類型是索引。 6. 約束等其他對象也應該盡可能包含所屬表或其他對象的名稱，以表明各自的關系 規則3：數據庫字段類型定義 1. 經常需要計算和排序等消耗CPU的字段,應該盡量選擇更為迅速的字段，如用`TIMESTAMP`(4個字節，最小值1970-01-01 00:00:00)代替`Datetime`（8個字節，最小值1001-01-01 00:00:00）,通過整型替代浮點型和字符型 2. 變長字段使用`varchar`，不要使用`char` 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)) 1. 聯合索引中的字段應盡量滿足過濾數據從多到少的順序，也就是說差異最大的字段應該房子第一個字段 2. 建立索引盡量與SQL語句的條件順序一致，使SQL語句盡量以整個索引為條件，盡量避免以索引的一部分(特別是首個條件與索引的首個字段不一致時)作為查詢的條件 3. `Where a=1,where a>=12 and a<15,where a=1 and b<5 ,where a=1 and b=7 and c>=40為條件可以用到此聯合索引；而這些語句where b=10,where c=221,where b>=12 and c=2則無法用到這個聯合索引。` 4. 當需要查詢的數據庫字段全部在索引中體現時，數據庫可以直接查詢索引得到查詢信息無須對整個表進行掃描(這就是所謂的key-only)，能大大的提高查詢效率。 當a，ab，abc與其他表字段關聯查詢時可以用到索引 5. 當a，ab，abc順序而不是b，c，bc，ac為順序執行Order by或者group不要時可以用到索引 6. 以下情況時，進行表掃描然后排序可能比使用聯合索引更加有效 a.表已經按照索引組織好了 b.被查詢的數據站所有數據的很多比例。 規則17：重要業務訪問數據表時。但不能通過索引訪問數據時，應該確保順序訪問的記錄數目是有限的，原則上不得多于10. ## 二.Query語句與應用系統優化 規則18：合理構造Query語句 1. Insert語句中，根據測試，批量一次插入1000條時效率最高，多于1000條時，要拆分，多次進行同樣的插入，應該合并批量進行。注意query語句的長度要小于mysqld的參數 max_allowed_packet 2. 查詢條件中各種邏輯操作符性能順序是and,or,in,因此在查詢條件中應該盡量避免使用在大集合中使用in 3. 永遠用小結果集驅動大記錄集，因為在mysql中，只有Nested Join一種Join方式，就是說mysql的join是通過嵌套循環來實現的。通過小結果集驅動大記錄集這個原則來減少嵌套循環的循環次數，以減少IO總量及CPU運算次數 4. 盡量優化Nested Join內層循環。 5. 只取需要的columns，盡量不要使用select * 6. 僅僅使用最有效的過濾字段，where 字句中的過濾條件少為好 7. 盡量避免復雜的Join和子查詢 Mysql在并發這塊做得并不是太好，當并發量太高的時候，整體性能會急劇下降，這主要與Mysql內部資源的爭用鎖定控制有關，MyIsam用表鎖，InnoDB好一些用行鎖。 規則19：應用系統的優化 1. 合理使用cache，對于變化較少的部分活躍數據通過應用層的cache緩存到內存中，對性能的提升是成數量級的。 2. 對重復執行相同的query進行合并，減少IO次數。 3. 事務相關性最小原則