復雜的數據需求的MySQL方案是怎樣的

今天就跟大家聊聊有關復雜的數據需求的MySQL方案是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

   前些天處理了一個需求，當時的數據庫環境是Oracle，我算是想盡了Oracle相關的方案，而且在問題的處理過程中，還在不斷的琢磨，如果失敗了還有什么其他的方案。

   所以盡管Oracle這么一個成熟的商業數據庫，做起來還是有些難度，需要一些額外的技巧，比如規避bug,間接實現需求等。

   但是換個角度，2億多數據的表，其實MySQL也不是新鮮事兒了。如果MySQL碰到了這種情況，該怎么處理呢。

梳理業務需求

  假設業務需求還是不變，如下：

   業務同學反饋，數據庫中有一個表數據量很大，因為要做一期活動，需要近期的數據，以前的舊數據可以考慮清理。清理多少舊數據呢，差不多是99%的量，數據量有多大呢，差不多兩個億。所以這個需求聽起來蠻簡單，但是業務同學明確希望能夠保持業務的可持續性，這樣一來就對實現方案有了一些選擇。

   這個看起來簡單的需求，有下面的一些補充信息，數據庫為MySQL 5.6,數據量有2億，數據查詢效率非常差，99%以上都是臟數據，需要清理，開發同學是根據時間范圍來進行查詢；表里的數據只有insert,沒有update和delete。

總結下來，要做4件事情：

1. 優化查詢，目前是基于時間范圍來查詢，經過評估需要給這個表添加索引

2. 清理數據，表里有兩億數據，但是要清理絕大部分數據。

3. 保證業務的可持續性，每10分鐘會做一次統計分析，數據會實時錄入系統

4. 把表修改為分區表，把舊數據放入一個分區，新數據放入另一個分區，變更之后刪除就分區即可

梳理需求優先級

如此一來，給這個表添加索引就是亟待解決的關鍵問題。

MySQL里面的online DDL功能還是很不錯的，對于索引的操作，5.6版本支持還是很全的。

所以MySQL online DDL原生的方案就很不錯，如果是5.5也沒關系還有pt-osc工具等可以實現。

大道至簡，思路相通

   而對此的一個解決方案如下，數據流和之前Oracle的方案如出一轍，但是實現原理和細節有所差別。

   首先需要做得就是生成一個影子表serverlog_read,對于源庫的表數據變更都能夠同步到這個表里。

   MySQL里面是不支持物化視圖的，所以增量刷新等等方案就會受限，但是辦法總比困難多，MySQL里面要實現物化視圖還是有一些其他的方法的，比如說Flexviews，或者是自己實現，通過觸發器的形式來實現需求，這里insert,delete,update都需要有觸發條件，所以pt工具默認會創建的也是3個觸發器，原理很相似。

    有了這個物化視圖，緩存增量數據就有了基本保證，所以我們還需要兩個輔助的表，一個是serverlog_par_old，這是個分區表，只保留一個分區，里面會存放物化視圖里查到的刷新數據，另外一個是serverlog_host,這里面存放的是增量數據和實時錄入系統的數據。

    這個時候其實有三種類別的數據處理需要考慮，第一類是舊數據，也可以理解為冷數據，第二類是增量數據，比如指定近一個月的數據需要保留，那么這個時間范圍內的數據就是增量數據，第三類是實時數據，數據會實時錄入系統，這個數據近乎是實時的。所以說上面的方案就是對冷數據能夠歸檔，對增量數據能夠合理截取，對實時數據產生盡可能小的影響。

   2億的數據怎么合1千萬的數據進行切換呢，MySQL 5.6也是支持exchange partition的。所以這個操作支持起來是沒有問題的，畢竟分區的操作就是這么幾種玩法。MySQL因為其自身存儲的特性，實現這個需求其實更純粹。

    最后就是增量，實時數據的補錄，利用serverlog_hot來補數據就行。

方案之外的兩點補充

    額外補充兩點，也是MySQL在這個實現過程的兩個亮點。

    第一個亮點就是MySQL復制表結構有著得天獨厚的優勢，大家知道在MySQL 5.6中是不支持create table xxxx as select xx這種方式的，但是有很多更絕的方法。

    我們可以改寫為下面的方式來做：

   1.create table test1 like test; --這種方式能夠完整的復制DDL信息。

    或者使用show create table來做，當然這個略有些不方面，或者是使用mysqldump --no-date的方式來導出語句也可以。

   2.插入數據，比如insert into test1 select *from test;

  第二個亮點部分就是對于數據的備份歸檔，說簡單簡單，說復雜復雜，比如我們嚴格限定數據的有效性，不需要的舊數據就不在當前的數據庫中保留，但是為了實現基本的備份需求，我們可以使用rename user的方式來做。Oracle實現rename user還是有些復雜的，而MySQL實現起來就很輕巧。說得通俗一些，就是把里面的數據挪到另外一個目錄下了。

  要處理這樣一個需求，毫無疑問盡管我信息滿滿，但是在實踐的時候還是是困難重重，碰到了問題多思考和總結，就會形成自己的認知體系，會少走很多彎路。

看完上述內容，你們對復雜的數據需求的MySQL方案是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。