MySQL 資料庫設計總結

2021-08-07 16:38:12 字數 4137 閱讀 2567

規則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.

規則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次數。

事務相關性最小原則

提問:如何設計或優化千萬級別的大表?此外無其他資訊,個人覺得這個話題有點範,就只好簡單說下該如何做,對於乙個儲存設計,必須考慮業務特點,收集的資訊如下:

1.資料的容量:1-3年內會大概多少條資料,每條資料大概多少位元組;

2.資料項:是否有大字段,那些欄位的值是否經常被更新;

3.資料查詢sql條件:哪些資料項的列名稱經常出現在where、group by、order by子句中等;

4.資料更新類sql條件:有多少列經常出現update或delete 的where子句中;

5.sql量的統計比,如:select:update+delete:insert=多少?

6.預計大表及相關聯的sql,每天總的執行量在何數量級?

7.表中的資料:更新為主的業務 還是 查詢為主的業務

8.打算採用什麼資料庫物理伺服器,以及資料庫伺服器架構?

9.併發如何?

10.儲存引擎選擇innodb還是myisam?

大致明白以上10個問題,至於如何設計此類的大表,應該什麼都清楚了!

至於優化若是指建立好的表,不能變動表結構的話,那建議innodb引擎,多利用點記憶體,減輕磁碟io負載,因為io往往是資料庫伺服器的瓶頸

另外對優化索引結構去解決效能問題的話,建議優先考慮修改類sql語句,使他們更快些,不得已只靠索引組織結構的方式,當然此話前提是,

索引已經建立的非常好,若是讀為主,可以考慮開啟query_cache,

以及調整一些引數值:sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size 

MySQL資料庫設計總結

規則1 一般情況可以選擇myisam儲存引擎,如果需要事務支援必須使用innodb儲存引擎。注意 myisam儲存引擎 b tree索引有乙個很大的限制 參與乙個索引的所有欄位的長度之和不能超過1000位元組。另外myisam資料和索引是分開,而innodb的資料儲存是按聚簇 cluster 索引有...

MySQL資料庫設計總結

規則1 一般情況可以選擇myisam儲存引擎,如果需要事務支援必須使用innodb儲存引擎。注意 myisam儲存引擎 b tree索引有乙個很大的限制 參與乙個索引的所有欄位的長度之和不能超過1000位元組。另外myisam資料和索引是分開,而innodb的資料儲存是按聚簇 cluster 索引有...

MySQL 資料庫設計總結

規則1 一般情況可以選擇myisam儲存引擎,如果需要事務支援必須使用innodb儲存引擎。注意 myisam儲存引擎 b tree索引有乙個很大的限制 參與乙個索引的所有欄位的長度之和不能超過1000位元組。另外myisam資料和索引是分開,而innodb的資料儲存是按聚簇 cluster 索引有...