規則1：一般情況可以選擇myisam儲存引擎，如果需要事務支援必須使用innodb儲存引擎。
注意：myisam儲存引擎 b-tree索引有乙個很大的限制：參與乙個索引的所有欄位的長度之和不能超過1000位元組。另外myisam資料和索引是分開，而innodb的資料儲存是按聚簇(cluster)索引有序排列的，主鍵是預設的聚簇(cluster)索引，因此myisam雖然在一般情況下，查詢效能比innodb高，但innodb的以主鍵為條件的查詢效能是非常高的。
規則2：命名規則。
資料庫和表名應盡可能和所服務的業務模組名一致
服務與同乙個子模組的一類表應盡量以子模組名(或部分單詞)為字首或字尾
表名應盡量包含與所存放資料對應的單詞
欄位名稱也應盡量保持和實際資料相對應
聯合索引名稱應盡量包含所有索引鍵欄位名或縮寫，且各欄位名在索引名中的順序應與索引鍵在索引中的索引順序一致，並盡量包含乙個類似idx的字首或字尾，以表明期物件型別是索引。
約束等其他物件也應該盡可能包含所屬表或其他物件的名稱，以表明各自的關係
規則3：資料庫字段型別定義
經常需要計算和排序等消耗cpu的字段,應該盡量選擇更為迅速的字段，如用timestamp(4個位元組，最小值1970-01-01 00:00:00)代替datetime(8個位元組，最小值1001-01-01 00:00:00),通過整型替代浮點型和字元型
變長字段使用varchar，不要使用char
對於二進位制多**資料，流水佇列資料(如日誌)，超大文字資料不要放在資料庫欄位中
規則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))
聯合索引中的字段應盡量滿足過濾資料從多到少的順序，也就是說差異最大的字段應該房子第乙個字段
建立索引盡量與sql語句的條件順序一致，使sql語句盡量以整個索引為條件，盡量避免以索引的一部分(特別是首個條件與索引的首個欄位不一致時)作為查詢的條件
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則無法用到這個聯合索引。
當需要查詢的資料庫字段全部在索引中體現時，資料庫可以直接查詢索引得到查詢資訊無須對整個表進行掃瞄(這就是所謂的key-only)，能大大的提高查詢效率。當a，ab，abc與其他表字段關聯查詢時可以用到索引
當a，ab，abc順序而不是b，c，bc，ac為順序執行order by或者group不要時可以用到索引
以下情況時，進行表掃瞄然後排序可能比使用聯合索引更加有效a.表已經按照索引組織好了b.被查詢的資料站所有資料的很多比例。
規則17：重要業務訪問資料表時。但不能通過索引訪問資料時，應該確保順序訪問的記錄數目是有限的，原則上不得多於10.
二.query語句與應用系統優化
規則18：合理構造query語句
insert語句中，根據測試，批量一次插入1000條時效率最高，多於1000條時，要拆分，多次進行同樣的插入，應該合併批量進行。注意query語句的長度要小於mysqld的引數 max_allowed_packet
查詢條件中各種邏輯操作符效能順序是and,or,in,因此在查詢條件中應該盡量避免使用在大集合中使用in
永遠用小結果集驅動大記錄集，因為在mysql中，只有nested join一種join方式，就是說mysql的join是通過巢狀迴圈來實現的。通過小結果集驅動大記錄集這個原則來減少巢狀迴圈的迴圈次數，以減少io總量及cpu運算次數
盡量優化nested join內層迴圈。
只取需要的columns，盡量不要使用select *
僅僅使用最有效的過濾字段，where 字句中的過濾條件少為好
盡量避免複雜的join和子查詢mysql在併發這塊做得並不是太好，當併發量太高的時候，整體效能會急劇下降，這主要與mysql內部資源的爭用鎖定控制有關，myisam用表鎖，innodb好一些用行鎖。
規則19：應用系統的優化
合理使用cache，對於變化較少的部分活躍資料通過應用層的cache快取到記憶體中，對效能的提公升是成數量級的。
對重複執行相同的query進行合併，減少io次數。
事務相關性最小原則
mysql資料庫索引的優化，實踐，實操
實驗乙個有43萬資料的表，索引情況 對uid設定了unique 約束唯一標識資料庫表中的每條記錄 唯一索引 對mobile設定了normal 普通索引 1 檢視數量 這裡的原因是字段有null的情況，就會全表查詢，然而加上 is not null 就會使索引生效，在字段沒有null的情況索引生效。2...
MySQL資料庫實操教程 09 更新資料
自定義view系列教程00 推翻自己和過往，重學自定義view 自定義view系列教程01 常用工具介紹 自定義view系列教程02 onmeasure原始碼詳盡分析 自定義view系列教程03 onlayout原始碼詳盡分析 自定義view系列教程04 draw原始碼分析及其實踐 自定義view系...
MySQL資料庫實操教程 11 簡單查詢
自定義view系列教程00 推翻自己和過往，重學自定義view 自定義view系列教程01 常用工具介紹 自定義view系列教程02 onmeasure原始碼詳盡分析 自定義view系列教程03 onlayout原始碼詳盡分析 自定義view系列教程04 draw原始碼分析及其實踐 自定義view系...