前些天處理了乙個需求，當時的資料庫環境是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 ***x 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實現起來就很輕巧。說得通俗一些，就是把裡面的資料挪到另外乙個目錄下了。
要處理這樣乙個需求，毫無疑問儘管我資訊滿滿，但是在實踐的時候還是是困難重重，碰到了問題多思考和總結，就會形成自己的認知體系，會少走很多彎路。
乙個奇葩的需求
今天和朋友聊天突然給我說拍一下錄取通知書封面，一解釋原因原來是小夥伴碰到了乙個奇葩需求。拍攝內容 錄取通知書封面 拍攝要求 1 拍攝角度在通知書正上方，通知書要是原來的形狀，不要產生形變。主要內容為通知書，通知書邊上留一部分空白 2 最好用相機，用手機拍的話發原圖 3 拍攝時在明亮處拍攝，同時通知書...
乙個需求的反思
在實際的工作中，一般來說，產品在召開需求評審會時，會邀請開發來參與評審，如果開發人數很多，往往只會邀請開發經理來參與評審，參與評審完後，由開發經理來分解模組，分配給相關的開發人員。這從產品需求到真正開發人員中間多了一道，會有需求資訊傳遞的損失，這是不可避免的。產品在需求規格說明書上面進行的需求描述，...
乙個需求的反思
在實際的工作中，一般來說，產品在召開需求評審會時，會邀請開發來參與評審，如果開發人數很多，往往只會邀請開發經理來參與評審，參與評審完後，由開發經理來分解模組，分配給相關的開發人員。這從產品需求到真正開發人員中間多了一道，會有需求資訊傳遞的損失，這是不可避免的。產品在需求規格說明書上面進行的需求描述，...