共計 2161 個字符，預計需要花費 6 分鐘才能閱讀完成。
今天就跟大家聊聊有關復雜的數據需求的 MySQL 方案是怎樣的，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
前些天處理了一個需求，當時的數據庫環境是 Oracle，我算是想盡了 Oracle 相關的方案，而且在問題的處理過程中，還在不斷的琢磨，如果失敗了還有什么其他的方案。
所以盡管 Oracle 這么一個成熟的商業數據庫，做起來還是有些難度，需要一些額外的技巧，比如規避 bug, 間接實現需求等。
但是換個角度，2 億多數據的表，其實 MySQL 也不是新鮮事兒了。如果 MySQL 碰到了這種情況，該怎么處理呢。
梳理業務需求
假設業務需求還是不變，如下：
業務同學反饋，數據庫中有一個表數據量很大，因為要做一期活動，需要近期的數據，以前的舊數據可以考慮清理。清理多少舊數據呢，差不多是 99% 的量，數據量有多大呢，差不多兩個億。所以這個需求聽起來蠻簡單，但是業務同學明確希望能夠保持業務的可持續性，這樣一來就對實現方案有了一些選擇。
這個看起來簡單的需求，有下面的一些補充信息，數據庫為 MySQL 5.6, 數據量有 2 億，數據查詢效率非常差，99% 以上都是臟數據，需要清理，開發同學是根據時間范圍來進行查詢；表里的數據只有 insert, 沒有 update 和 delete。
總結下來，要做 4 件事情：
優化查詢，目前是基于時間范圍來查詢，經過評估需要給這個表添加索引
清理數據，表里有兩億數據，但是要清理絕大部分數據。
保證業務的可持續性，每 10 分鐘會做一次統計分析，數據會實時錄入系統
把表修改為分區表，把舊數據放入一個分區，新數據放入另一個分區，變更之后刪除就分區即可
梳理需求優先級
如此一來，給這個表添加索引就是亟待解決的關鍵問題。
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 方案是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
