通用增量數據同步方案
同步處理時間
① 每次增量同步時間為上一次同步成功的開始時間往前推5分鍾。而不是同步成功的結束時間（往前推5分鍾的目的是避免服務方數據落地事務
延遲導致的數據丟失問題）；
② 是否需要開啟事務：評估如果部分失敗不影響系統功能和業務，則同步任務不需要開啟事務，避免大事務連接超時，主從同步等問題；
③ 數據查詢需要做分頁查詢，避免數據量過大導致內存溢出或者請求超時等問題；
④ 分頁查詢需要按照有序的、沒有重復數據的、而且不會發生變化的字段進行升序排序，比如，自增id（否則會導致數據丟失或者重復等問
題）；
⑤ 使用增量同步數據的前提是：數據源每次的數據變化必須都更新最后更改時間，記錄的刪除采用邏輯刪除（is_deleted=N/Y）。
通用增量數據同步方案-數據丟失問題1
因排序不當導致數據丟失/重復的情況演繹：按照last_update_date排序
解決：按照id這種有序的而且字段值不會重復和發生變化的字段進行排序。
通用增量數據同步方案-數據丟失問題2
結論：不會丟失。因為Id=3的記錄最后更改時間其實是大於本次同步
的開始時間，在下一次同步的時候這條記錄會被撈取到。
解決方案演繹：通過Id排序
通用增量數據同步方案-數據丟失問題3
數據源應用中，數據落地延遲導致數據丟失的情況演繹：
解決：每次同步的時間設置為上次的同步開始時間再往前推5分鍾。
分頁查詢性能問題解決方案
問題：MySQL並不是跳過offset行，而是取offset+N行，然后放棄前offset行，返回N行，
那當offset特別大的時候，效率就非常的低下，要么控制返回的總頁數，要么對超過特定閾
值的頁數進行SQL改寫
解決：先快速定位分頁數據對應的id，再根據id關聯取得對應的行數據。
通過索引index_last_update_date直接查找到id，不需要回表，所以定位到這1000個id是很快的。再按照這1000個
id拿1000條數據，這是按照主鍵索引取得，性能也不錯。整個處理方式避免了查詢過程中大量的IO，從而提高查
詢性能。
增量同步記錄表設計
增量同步例子-分頁小批量處理
增量同步例子-數據源查詢
其他同步方案
