本文由雲 + 社群發表
規則 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考勤資料庫設計 mysql 資料庫設計
正規化 大概有8種正規化，遵循前三個一般資料庫就沒有問題 1 列不能再拆分 比如一列中有姓名，又有性別，就是沒有遵循這一條正規化 order id product id price quantity product name 111 11 123 good pen order id 和 produc...
mysql相簿資料庫設計 mysql資料庫的設計
資料庫的設計有乙個嚴謹的流程，根據流程製作乙個完整的資料庫，可以省去很多的時間，也可以最大程度上與客戶的想法契合。需求分析階段 分析客戶的業務和資料處理需求 概要設計階段 設計資料庫的e r模型圖，確認需求資訊的正確和完整 詳細設計階段 應用三大正規化審核資料庫結構 編寫階段 物理實現資料庫，編碼實...
mysql資料庫設計
在進行優化工作之前，先應該按照業務需求設計資料庫，這邊寫的十分詳細 另外，根據業務弄清楚幾個問題 1.資料的容量 1 3年內會大概多少條資料，每條資料大概多少位元組 2.資料項 是否有大字段，那些欄位的值是否經常被更新 3.資料查詢sql條件 哪些資料項的列名稱經常出現在where group by...