mysql進階特性-合并表
merge存儲引擎把一組myisam資料表當做一個邏輯單元來對待,讓我們可以同時對他們進行查詢。構成一個merge資料表結構的各成員myisam資料表必須具有完全一樣的結構。每一個成員資料表的資料列必須按照同樣的順序定義同樣的名字和類型,索引也必須按照同樣的順序和同樣的方式定義。
合并表對性能的影響
mysql對合并表的實作對性能有一些重要的影響。和其他mysql特性一樣,它在某些條件下性能會更好。下面是關于它的一些注意事項:
1) 合并表比含有同樣資料的非合并表需要更多的檔案描述符。盡管合并表看上去是一個表,它實際是逐個打開了下屬表。這樣的結果就是單個表的緩存可以建立許多檔案描述符。是以,即使已經配置了表的緩存,讓伺服器線程的檔案描述符數量不要超過作業系統的限制,合并表仍然有可能導緻超過這一限制。
2) 建立合并表的create語句不會檢查下屬表是否是相容的。如果下屬表的定義有輕微的不一樣,mysql會建立合并表,但是卻無法使用。同樣,如果在建立了一個有效的合并表之後對某個下屬表進行了改變,它也會無法工作,并且會顯示下面的錯誤資訊:"error 1168(hy000):無法打開定義不同的下屬表,或者非myisam表,或者不存在的表"。
3)通路合并表的查詢通路了每一個下屬表。這也許會使單行鍵查找比單個表慢。在合并表中限制下屬表是一個好主意,尤其是它是聯接中的第二個或以後的表。每次操作通路的資料越少,那麼通路每個表的開銷相對于整個操作而言就越重要。下面是一些如何使用合并表的注意事項:
4)範圍查找受通路所有下屬表的開銷的影響小于單個查找。
對索引表的表掃描和對單個表一樣快。
一旦唯一鍵和主鍵查詢成功,它們就立即停止。在這種情況下,伺服器會挨個通路下屬表,一旦查找到了值,就不會再查找更多的表。
下屬表讀取的順序和creat table語句中定義的一緻。如果經常需要按照特定的順序取得資料,可以利用這種特性使合并排序操作更快。
合并表的長處
合并表在處理資料方面既有積極的一面,也有消極的一面。
1) 經典的例子就是日志記錄。日志是隻追加的,是以可以每天用一個表。每天建立新的表并把它加入到合并表中。也可以把以前的表從合并表中移除掉,把它轉化為壓縮的myisam表,再把它們加回到合并表中。
2) 日志追加這并不是合并表的唯一用途。它們通常都被用于資料倉庫程式,因為它的另一個長處就是管理大量的資料。在實際中不太可能管理一個tb級别的表,但是如果是由單個50gb的表組成的合并表,任務就會簡單很多。
當管理極其巨大的資料庫時,考慮的絕不僅僅是正常操作。還要考慮崩潰與恢複。使用小表是很好的主意。檢查和修複一系列的小表比起一個大表要快得多,尤其是大表和記憶體不比對的時候。還可以并行地檢查和修複多個小表。
資料倉庫中另外一個顧慮就是如何清理掉老的資料。對巨型表使用delete語句最佳狀況下效率不高,而在最壞情況下則是一場災難。但是更改合并表的定義是很簡單的,可以使用drop table指令删除老的資料。這可以輕易地實作自動化。
3) 合并表并非隻對日志和大量資料有效。它可以友善地按需建立繁忙的表。建立和删除合并表的代價是很低的。索引可以像對視圖使用union all指令那樣使用合并表。但它的開銷更低,因為伺服器不會把結果放到臨時表中然後再傳遞給用戶端。這使得它對于報告和倉庫化資料非常有用。例如,要建立一個每晚都會運作的任務,它會把昨天的資料和8天前、15天前、以及之前的每一周的資料進行合并。使用合并表就可以建立無須修改的查詢,并且自動地通路合适的資料。甚至還可以建立臨時合并表,這是視圖無法做到的。
因為合并表沒有隐藏下屬的myisam表,是以它提供了一些分區表無法提供的特性:
一個myisam表可以包含很多合并表。
可以通過拷貝.frm、.myi、.myd檔案在伺服器之間拷貝下屬表。
可以輕易地把更多的表添加到合并表中。這隻需要建立一個新表并且更改合并定義即可。
可以建立隻包含想要的資料的臨時合并表,例如某個特定時間段的資料。這是分區表無法做到的。
如果想對某個表進行備份、恢複、更改、修複,或者其他的操作,可以把它從合并表中移除,完成所有的工作之後再把它加回來。
可以使用myisampack壓縮某些或所有的下屬表。
分區表正好相反,mysql隐藏了分區表的分區,并隻能通過分區表通路所有的分區
變通方案:
建立一個視圖,但是要每個月重建一次,把新表包含進來,這樣可以用到innodb表
具體方案:
建立視圖,最新資料資料寫入固定表,例如t_data,當某個月一号,把曆史數導入到上個月名稱的一個曆史表,例如t_data_201811
視圖是v_data包含曆史表(.......,t_data_201811)和目前表t_data