1. 程式人生 > >MySQL數據庫設計常犯的錯以及對性能的影響

MySQL數據庫設計常犯的錯以及對性能的影響

成本 strong 操作 主從 相關 解析 依賴 做的 這樣的

1.過分的反範式化為表建立太多的列

  我們在設計數據庫的結構時,比較容易犯的第一個錯誤就是對表進行了過分的反範式化的設計,這就容易造成了表中的列過多,雖然說Mysql允許為一個表建立很多的列,但是由於Mysql的插件式架構的原因,前面博客已經有介紹,Mysql的服務器層和存儲引擎層是分離的,Mysql的存儲引擎API工作時需要把服務器層和存儲引擎層之間通過緩沖格式來拷貝數據,然後在服務器層將緩沖層的數據解析成各個列,這個操作過程成本是非常高的,特別是對於MyISAM的變長結構,和Innodb這種行結構在解析時還必須進行轉換,這個轉換的成本呢就依賴於列的數量,所以,如果一個表的列過多,在使用這個表時就會帶來額外過多的cpu消耗。所以在進行表設計的時候一定要註意,不要把表相關的所有列都放在一個表中,而是要按照範式化適當的對表進行拆分,關於什麽是範式化,會另外的詳細介紹。

2.過分的使用範式化設計造成了太多的表關聯

  對數據庫的設計過分的使用了範式化設計的思路,對於任何的查詢都要關聯很多個表,通過前面的介紹,我們知道對Mysql進行表關聯查詢成本是非常高的,而且性能也會隨著關聯表的增加而下降,所以呢Mysql對表關聯的數量進行了限制,Mysql最多只可以關聯61個表,這個限制呢雖然對於大多數應用來說已經足夠了,但是我們為了Mysql的性能還是要盡量減少關聯的表,關聯的表數量最好在10個以內,這就要求我們在進行數據庫設計時候要進行適當的反範式化設計,把經常使用的兩個小表合成一個大表,這樣做對提升數據庫的性能和sql查詢的性能都是很有幫助的 。

3.在OLTP環境中使用不恰當的分區表

  分區表是一個好東西,可以幫助我們把一個大表在物理存儲上按照分區鍵分成多個小表,這裏要註意了,分區表和我們常說的分庫分表是有區別的,分區表是在同一個數據庫實例下進行的,而物理存儲上分成多個小表但是在使用時邏輯上還是使用一個表;而分庫分表所要做的操作不止是在物理上進行拆分而且邏輯上也會拆分多個表,而且分庫分表後多個表通常不是在一個數據庫實例下的。在使用分區表時,分區鍵的選擇非常關鍵,如果分區鍵的選擇不恰當,就會造成查詢時跨多個分區查詢,這樣不僅不會提升數據庫的性能,而且還會降低數據庫的查詢性能,所以建議在OLTP環境中使用分區表一定要註意,分區表最好還是在OLAP環境使用,或者對於一些日誌表使用還是比較合適的。

4.使用外鍵約束保證事務的完整性

   我們都知道InnoDB存儲引擎是事務型存儲引擎,它是支持事務和外鍵的,所以很多開發人員喜歡使用外鍵約束來保證數據的完整性,但是這樣的效率是非常低的,因為在對使用外鍵的表進行修改時,Mysql都會對外鍵約束來進行檢查,這樣呢就帶來了額外的鎖的開銷,降低了數據庫修改的效率;另外使用外鍵,在進行數據庫備份、恢復或者手動進行數據歸檔維護也會有問題,比如:我們不能使用truncate table對表快速的進行清空操作, 只能使用delete from進行,這樣在主從復制的環境下對一個大表的數據環境清理復雜度就會變得很高,所以強烈建議不要使用外鍵約束,但是在關聯鍵上建立相關的索引還是必須的

MySQL數據庫設計常犯的錯以及對性能的影響