企業(yè)如何做一次完美的數(shù)據(jù)遷移

1.數(shù)據(jù)遷移概述數(shù)據(jù)遷移，是一個(gè)非常復(fù)雜的過程，不僅僅是將數(shù)據(jù)從一個(gè)地方移動(dòng)到另一個(gè)地方。這里需要考慮業(yè)務(wù)定義、架構(gòu)變更、應(yīng)用改造、數(shù)據(jù)安全等諸多方面問題。在實(shí)際遷移工作中，需要結(jié)合企業(yè)的方方面面，做好合理的規(guī)劃及實(shí)施，否則很可能會(huì)導(dǎo)致遷移結(jié)果達(dá)不到預(yù)期，浪費(fèi)人力財(cái)力。在正式開始遷移之前，有幾項(xiàng)工作是需要提前考慮的。1).遷移目的在我們正式開展遷移之前，首先要對遷移目的有個(gè)清晰的定位。后面的很多工作的前提，正基于此。下面羅列下常見的目的，真實(shí)場景中可能包含一個(gè)或多個(gè)的組合。成本現(xiàn)有方案成本過高，因而考慮至低成本方案。這里需要關(guān)注幾點(diǎn)：遷移后方案的總體成本，不僅要考慮初期采購成本，也要考慮后期維護(hù)及商業(yè)方案中過了初始幾年后的持有成本。遷移方案本身的成本，這里包括經(jīng)濟(jì)、時(shí)間、人力、風(fēng)險(xiǎn)成本等多種因素。如實(shí)施失敗時(shí)，必要的回退成本，包括因此而產(chǎn)生的對業(yè)務(wù)的影響所到來的經(jīng)濟(jì)損失。性能現(xiàn)有方案不能滿足性能要求，這里需要考慮幾個(gè)問題：性能要求是否合理？是常態(tài)化需求，還是偶然高峰？未來業(yè)務(wù)增長對性能的要求多大？是否可在業(yè)務(wù)側(cè)、應(yīng)用側(cè)，通過必要的改造、升級滿足性能要求（畢竟前端的改造代價(jià)，比后端要小得多）？是否可在原有數(shù)據(jù)平臺(tái)上通過ScaleUp或者ScaleOut來解決性能問題？畢竟更換底層的平臺(tái)的代價(jià)很大?？臻g現(xiàn)有方案不能滿足容量要求，這里需要考慮幾個(gè)問題：當(dāng)前存量數(shù)據(jù)，是否可通過清理、轉(zhuǎn)儲(chǔ)、歸檔等手段，來減少現(xiàn)有容量？（水平拆分）現(xiàn)有數(shù)據(jù)是否是同質(zhì)的，即是否可通過分拆，劃分出獨(dú)立單元來承載業(yè)務(wù)？（垂直拆分）現(xiàn)有存量使用及未來增量情況，這些對于未來選型都很重要。自主可控隨著近些年來，內(nèi)外部環(huán)境和自上而下的政策性要求，對于企業(yè)核心技術(shù)的自主可控要求越來越高。因而對于國產(chǎn)化需求，日益高漲。技術(shù)演進(jìn)隨著企業(yè)自身的技術(shù)發(fā)展，對于后端數(shù)據(jù)平臺(tái)的要求不斷變化。例如數(shù)據(jù)中臺(tái)、微服務(wù)等興起，作為數(shù)據(jù)載體需求也有所變化。業(yè)務(wù)需求業(yè)務(wù)發(fā)展變化，也對于支撐平臺(tái)的需求不斷變化。軟硬件更換升級軟件，技術(shù)更替、版本迭代；特別是硬件，有著明顯的周期性特點(diǎn)。企業(yè)定期都會(huì)避免升級替換類訴求。2).業(yè)務(wù)場景分析在著手遷移之前，需要對現(xiàn)有業(yè)務(wù)做了全面的梳理，重點(diǎn)是將其對數(shù)據(jù)載體的要求整理清楚。為了滿足這些業(yè)務(wù)場景，未來的遷移需求是通過單一平臺(tái)還是通過多種異構(gòu)組合來完成？這些內(nèi)容對于后續(xù)遷移選型有著重要意義。在這個(gè)階段，還需要增加對未來的增長變化或業(yè)務(wù)調(diào)整導(dǎo)致的可能變化?？梢苑抡障卤?，完成場景分析工作。3).遷移需求分析在對業(yè)務(wù)場景做好必要的分析工作后，我們還需要針對遷移需求做更多細(xì)致的工作。這里包括：硬件環(huán)境業(yè)務(wù)系統(tǒng)使用的資源情況（CPU、MEM、STORAGE等）這些信息，一方面可用來為遷移后的技術(shù)選型做一定參考；另一方面在遷移階段也需做好對現(xiàn)有環(huán)境影響的評估。網(wǎng)絡(luò)環(huán)境業(yè)務(wù)系統(tǒng)的網(wǎng)絡(luò)配置和網(wǎng)絡(luò)隔離情況，包括組網(wǎng)邏輯、帶寬、隔離情況。這些對遷移實(shí)施，有著一定影響。操作系統(tǒng)業(yè)務(wù)系統(tǒng)使用的操作系統(tǒng)，是Linux還是Windows，是32位還是64位，其使用的文件系統(tǒng)是什么？安全策略業(yè)務(wù)系統(tǒng)的特殊安全要求，例如開放哪些端口、訪問權(quán)限。應(yīng)用系統(tǒng)應(yīng)用系統(tǒng)是采用商用的還是自研的，使用什么開發(fā)語言、版本是什么，接入類型（JDBC、ODBC等）？是否有專有的開發(fā)工具開發(fā)？是否使用了非標(biāo)準(zhǔn)接口？數(shù)據(jù)規(guī)模包括整體的數(shù)據(jù)規(guī)模及設(shè)計(jì)最大規(guī)格，單體對象的最大規(guī)模（行、列）。數(shù)據(jù)特征（結(jié)構(gòu)化or非結(jié)構(gòu)化）、數(shù)據(jù)類型等。數(shù)據(jù)安全指標(biāo)RTO、RPO等性能指標(biāo)MBPS、IOPS、RT等4).遷移難點(diǎn)數(shù)據(jù)安全數(shù)據(jù)是數(shù)據(jù)遷移的基本需求，如何在整個(gè)數(shù)據(jù)遷移操作過程中，保證數(shù)據(jù)的安全性是一項(xiàng)不小的挑戰(zhàn)。除了考慮在遷移前必要的數(shù)據(jù)備份外，還要考慮清楚遷移過程中數(shù)據(jù)增量問題，以及出現(xiàn)異常問題后的安全回退等。兼容性兼容性是整個(gè)數(shù)據(jù)遷移方案得以實(shí)施的前提。這里談到的兼容性，不僅包括與原有業(yè)務(wù)應(yīng)用系統(tǒng)的兼容，也包括與原有基礎(chǔ)平臺(tái)（監(jiān)控、預(yù)警、備份）及其他數(shù)據(jù)平臺(tái)的兼容。如存在不兼容之處，需要考慮之前的規(guī)避措施或做必要的調(diào)整。停機(jī)時(shí)間也就是業(yè)務(wù)遷移時(shí)間窗，這也常常是客戶最關(guān)心的話題，很多情況下客戶都是要求在線遷移。隨著數(shù)據(jù)量日益擴(kuò)大和業(yè)務(wù)的逐漸復(fù)雜，每次遷移停止和啟動(dòng)業(yè)務(wù)都需要消耗數(shù)小時(shí)時(shí)間，所以每一次數(shù)據(jù)遷移都是一場與時(shí)間賽跑的游戲，要求操作過程的全程可控。不僅要對正常流程的可控，還要做到在異常情況下的可控，保證即使出現(xiàn)各種異常，還能夠正常時(shí)間內(nèi)完成遷移或者回退。這里也要與客戶充分的溝通，如果能使用離線遷移方式，還是建議使用離線方式，畢竟這種方式的風(fēng)險(xiǎn)要小很多。數(shù)據(jù)校驗(yàn)在整個(gè)的數(shù)據(jù)遷移過程中，采用的遷移方式多種多樣。由于誤操作或者遷移方案缺陷極有可能導(dǎo)致數(shù)據(jù)庫數(shù)據(jù)的不一致。在遷移的過程中，應(yīng)該制定嚴(yán)格的數(shù)據(jù)驗(yàn)證過程。在遷移前后，要有充分的準(zhǔn)備。避免由于誤操作導(dǎo)致數(shù)據(jù)庫的數(shù)據(jù)庫準(zhǔn)確性問題。建議客戶采用并行混跑方式，有較長的時(shí)間窗口可以充分驗(yàn)證新環(huán)境的數(shù)據(jù)準(zhǔn)確性，避免出現(xiàn)發(fā)現(xiàn)異常而無法回退的情況。性能保證性能保證，也是客戶比較關(guān)心的一個(gè)問題。能否對遷移后環(huán)境性能變現(xiàn)有個(gè)準(zhǔn)確的預(yù)期，對客戶來說尤為重要；但要做到準(zhǔn)確的評估是比較困難的。一般建議在正式遷移之前，進(jìn)行預(yù)遷移在全量數(shù)據(jù)環(huán)境下的模擬壓力測試，驗(yàn)證性能表現(xiàn)。2.遷移過程：事前篇1).方案調(diào)研在遷移之前，最為重要的就是確定遷移方案。針對數(shù)據(jù)遷移，可以有很多類遷移方式，包括數(shù)據(jù)庫、存儲(chǔ)、虛擬機(jī)、卷、主機(jī)、網(wǎng)絡(luò)、應(yīng)用等等。這里需要根據(jù)我們的要求，圈定采用哪類遷移方式；然后是明確具體的遷移方案，如果涉及到外部商用方案，還需要進(jìn)行必要的POC測試；再次就是細(xì)化方案，確定具體遷移步驟（含遷移、回退、驗(yàn)證）等。下面描述下常見的這幾類遷移方案。數(shù)據(jù)庫方案如果是同種數(shù)據(jù)庫，可以采用備份、還原方式；異構(gòu)的話，可以采用導(dǎo)入、導(dǎo)出方式?，F(xiàn)在還有一種比較通用的方案，是消費(fèi)源端的日志，將其轉(zhuǎn)換成標(biāo)準(zhǔn)消息，然后對端消費(fèi)應(yīng)用。這種方式通用性較好，可實(shí)現(xiàn)同構(gòu)、異構(gòu)、跨平臺(tái)的遷移；增量部分，通過源端的日志實(shí)時(shí)捕獲，也可以實(shí)現(xiàn)。當(dāng)然對于全量數(shù)據(jù)來說，還是建議采取異步方式，集中處理，這樣效率比較高。虛擬機(jī)方案VMware、Hyper-V等虛擬化產(chǎn)品也都提供了在線替換遷移功能。虛擬機(jī)的在線遷移功能可以實(shí)現(xiàn)無中斷的遷移，但是并不是所有場景都可以使用這種方案進(jìn)行遷移。因此虛擬機(jī)遷移需要首先核對是否場景限制上能夠滿足。操作系統(tǒng)方案對于文件系統(tǒng)場景，由于各個(gè)廠商的元數(shù)據(jù)結(jié)構(gòu)不一樣，一般都需要通過文件遷移工具從文件層進(jìn)行拷貝和復(fù)制，保留文件的屬性和權(quán)限，而不能從底層塊數(shù)據(jù)層進(jìn)行遷移。所以文件系統(tǒng)相對簡單，常見的諸如Linux下Rsync工具，就是一個(gè)遠(yuǎn)程數(shù)據(jù)同步工具，可通過LAN或WAN快速同步多臺(tái)主機(jī)間的文件。卷方案在大多數(shù)操作系統(tǒng)上都提供卷管理軟件，將SAN裸設(shè)備進(jìn)行行聚合或者拆分后提供給上層應(yīng)用使用，因此絕大多數(shù)應(yīng)用數(shù)據(jù)都通過卷管理軟件進(jìn)行管理，所以卷管理軟件自帶的鏡像和遷移功能常常成為在線數(shù)據(jù)遷移方案的一種選擇。常見的如Linux下的LVM、Oracle自帶的ASM等，通過這些不同的卷管理軟件實(shí)現(xiàn)數(shù)據(jù)在線遷移到新的目標(biāo)存儲(chǔ)。網(wǎng)絡(luò)方案虛擬化網(wǎng)關(guān)產(chǎn)品通過自帶的存儲(chǔ)虛擬化功能可以實(shí)現(xiàn)遷移功能。比如筆者之前使用過的EMCVplex系列等。這種方式首先是通過虛擬化網(wǎng)產(chǎn)品將源存儲(chǔ)接管，讓源存儲(chǔ)和業(yè)務(wù)主機(jī)之間的所有數(shù)據(jù)都通過網(wǎng)關(guān)產(chǎn)品進(jìn)行傳遞，再通過網(wǎng)關(guān)產(chǎn)品將數(shù)據(jù)完整的從塊級別鏡像復(fù)制到目標(biāo)新存儲(chǔ)。這種方案具有很強(qiáng)的普適性，可以在大部分的場景下使用。但是由于鏡像復(fù)制只是實(shí)現(xiàn)了數(shù)據(jù)復(fù)制到目標(biāo)新存儲(chǔ)，而原來的業(yè)務(wù)主機(jī)上的多路徑，卷管理，集群和數(shù)據(jù)庫等軟件都是和源存儲(chǔ)進(jìn)行綁定的，因此在數(shù)據(jù)同步到目標(biāo)存儲(chǔ)的后，還需要將業(yè)務(wù)和源存儲(chǔ)的綁定關(guān)系替換為目標(biāo)存儲(chǔ)，這個(gè)過程是整個(gè)數(shù)據(jù)遷移過程中最復(fù)雜的部分。存儲(chǔ)方案存儲(chǔ)設(shè)備本身也具備一些數(shù)據(jù)遷移功能，如LUN拷貝和遠(yuǎn)程復(fù)制。LUN拷貝可以把目標(biāo)新存儲(chǔ)作為一個(gè)服務(wù)器，首先將源存儲(chǔ)映射到目標(biāo)新存儲(chǔ)，再將目標(biāo)新存儲(chǔ)上的所有數(shù)據(jù)讀出來寫到目標(biāo)存儲(chǔ)上。遠(yuǎn)程復(fù)制可以從數(shù)據(jù)塊層面將數(shù)據(jù)從一臺(tái)存儲(chǔ)同步到遠(yuǎn)端的另一套存儲(chǔ)，但一般要求源存儲(chǔ)和目標(biāo)存儲(chǔ)都是來自一家的同平臺(tái)產(chǎn)品。此功能經(jīng)常被用于存儲(chǔ)的跨地域數(shù)據(jù)遷移。應(yīng)用方案應(yīng)用方案，可以說是萬能的方案，客戶可根據(jù)自身情況定制遷移方案。其往往是最靈活的，當(dāng)然也是復(fù)雜度相對較高的一種。常用的方法開發(fā)一個(gè)全量的遷移工具，進(jìn)行數(shù)據(jù)遷移；增量部分，采用讀取源端日志的方式補(bǔ)齊；此外配合必要的數(shù)據(jù)對比工具完成。在新舊系統(tǒng)數(shù)據(jù)基本同步后，斷掉舊系統(tǒng)，切換到新系統(tǒng)。這種方式可以實(shí)現(xiàn)比較平滑的遷移，全程可控；但問題在于如果出現(xiàn)問題，還需考慮回退流程，最好能實(shí)現(xiàn)雙向同步，但這種復(fù)雜度又增大不少。還有一種就是所謂的“雙寫法”，先利用數(shù)據(jù)同步工具完成初始的數(shù)據(jù)同步，對于增量部分采用應(yīng)用雙寫的方式完成，這里只要保證必要的數(shù)據(jù)冪等性即可。在切換流程上，通常采用六個(gè)階段。第一階段，上線雙寫，即同時(shí)寫入新舊兩種系統(tǒng)數(shù)據(jù)；第二階段，歷史數(shù)據(jù)離線搬遷，即離線將歷史存量數(shù)據(jù)從舊系統(tǒng)搬到新系統(tǒng)；第三階段，切讀，即將讀請求部分或全部路由到新系統(tǒng)；第四階段，切寫，即將寫請求部分或全部路由到新系統(tǒng)；第五階段，全部切換至新系統(tǒng)，即讀寫請求都走新系統(tǒng)，此時(shí)雙寫并沒有停止，依然保證新舊兩邊的數(shù)據(jù)完全一致，目前是為了保證異常時(shí)可直接回切。視測試情況，這個(gè)階段可保持較長時(shí)間，充分驗(yàn)證新系統(tǒng)的數(shù)據(jù)準(zhǔn)確性、性能表現(xiàn)等。第六階段，停寫，即將舊系統(tǒng)的寫入停止，清理回收舊系統(tǒng)資源，全部流程結(jié)束。2).方案測試在明確了遷移方案后，需進(jìn)行完備的方案測試；如涉及到自研部分，需盡早啟動(dòng)開發(fā)工作。如要采購?fù)獠慨a(chǎn)品，也需要在此階段進(jìn)行測試。這個(gè)階段的測試，主要目的是驗(yàn)證方案可行性，特別是數(shù)據(jù)安全方面。對可能出現(xiàn)的風(fēng)險(xiǎn)，要充分評估，并將其納入到后續(xù)方案細(xì)節(jié)中。此外，也需要在此階段收集必要的性能數(shù)據(jù)，為后續(xù)評估新系統(tǒng)配置、停機(jī)窗口等，做必要的準(zhǔn)備。如有多種方案均可行，也可以在測試階段具體比較其差異，找出最為適合的一種。3.遷移過程：事中篇在整體遷移過程中，一般遵循從規(guī)劃階段->準(zhǔn)備階段->遷移階段->驗(yàn)證階段->投產(chǎn)階段的順序。當(dāng)在驗(yàn)證階段出現(xiàn)問題時(shí)，可能需要回溯到規(guī)劃階段進(jìn)行調(diào)整甚至放棄此方案；但投產(chǎn)階段出現(xiàn)問題是，需要退回到驗(yàn)證階段重新評測優(yōu)化。（下面的遷移方案中，按照最為常見的數(shù)據(jù)庫遷移方案進(jìn)行說明）1).規(guī)劃階段總體規(guī)劃整個(gè)遷移過程會(huì)涉及數(shù)據(jù)庫廠商、應(yīng)用開發(fā)商、客戶等多個(gè)部門和組織的配合，為了保證遷移項(xiàng)目的成功，每一個(gè)環(huán)節(jié)都要仔細(xì)分析并充分驗(yàn)證?？傮w規(guī)劃尤為重要，建議成立虛擬的指揮中心協(xié)調(diào)各方資源推進(jìn)。資源規(guī)劃資源部分，主要是指遷移設(shè)計(jì)的硬件部分。包括硬件規(guī)劃、選型、評測、采購等。如涉及多種設(shè)備（主機(jī)、存儲(chǔ)、網(wǎng)絡(luò)等），還需要考慮之間的兼容適配問題。此外，與現(xiàn)有平臺(tái)的兼容能力也需考慮。如果涉及到國產(chǎn)化問題，還需要考慮上層軟件的適配問題。遷移規(guī)劃制定詳細(xì)周密的遷移計(jì)劃，包括整個(gè)后面“準(zhǔn)備+遷移+驗(yàn)證+投產(chǎn)”的全流程。細(xì)節(jié)要詳細(xì)到每一操作步驟，甚至要求全部腳本化，不能臨時(shí)敲命令處理。所有步驟的預(yù)期結(jié)果，需要明示。在出現(xiàn)之前未評估結(jié)果時(shí)，需啟動(dòng)應(yīng)急流程處理。此外，一定不要忽視回退計(jì)劃。測試規(guī)劃在遷移中的每一階段，都要制定測試計(jì)劃，做到步步可驗(yàn)證。這里的測試可從系統(tǒng)級、數(shù)據(jù)級、應(yīng)用級、業(yè)務(wù)級多方面去考察，保證最后結(jié)果的正確性。驗(yàn)收規(guī)劃在系統(tǒng)投產(chǎn)之后，需要有個(gè)標(biāo)志性的環(huán)節(jié)，就是“驗(yàn)收”。這代表著本次遷移工作是否成功，可否將業(yè)務(wù)正式切換過來。一般建議，在系統(tǒng)上線投產(chǎn)后，一段時(shí)間之后再考慮。但需要在之前制定一個(gè)標(biāo)準(zhǔn)。2).準(zhǔn)備階段硬件環(huán)境各種硬件的上架、聯(lián)調(diào)，系統(tǒng)安裝、部署等。角色授權(quán)在遷移之前開通必要的安全通路，開啟可訪問線上通路。業(yè)務(wù)準(zhǔn)備業(yè)務(wù)端做好必要的準(zhǔn)備，例如掛公告等，為正式遷移做好準(zhǔn)備。3).遷移階段權(quán)限遷移這里包括用戶、角色、權(quán)限遷移。需要考慮的是，原有這部分是否做調(diào)整，是否拆分、整合，是否做隔離。切記避免出現(xiàn)，可訪問舊系統(tǒng)的情況，造成數(shù)據(jù)污染，乃至無法回退的情況。對象遷移也叫元數(shù)據(jù)遷移。這部分涉及內(nèi)容很多，也是最為復(fù)雜的部分。常見包括以下一些方面：字段類型如果是異構(gòu)系統(tǒng)遷移，需要建立新舊系統(tǒng)的字段映射關(guān)系。對于無法直接映射的部分，要考慮如何轉(zhuǎn)化實(shí)現(xiàn)。特別需要注意的是精度問題，不同數(shù)據(jù)庫產(chǎn)品的相同類型字段，其精度有可能有差異。此外，還有諸如符號位等問題?？梢蕴崆白鲆粋€(gè)映射表，既方便查看，也方便研發(fā)人員對照。這部分也可利用一些工具輔助完成。約束字段作為常見的五大類約束（PK、FK、UK、NULL、CHECK），是否在新平臺(tái)全部原樣支持。此外有些平臺(tái)原生就不完全支持，此時(shí)要考慮好解決對策。此外，如果應(yīng)用使用了業(yè)務(wù)主鍵，也要考慮遷移后是否有影響。特殊字段在源或目標(biāo)端，有一些特殊字段需要在對象遷移階段給予關(guān)注。例如自增類型、分布鍵、分區(qū)鍵等。這些需要特殊考慮，往往需要人工指定。字符集問題為避免出現(xiàn)導(dǎo)入后亂碼等問題，需要在這個(gè)階段就考慮。特別是如果目標(biāo)端的字符集只能做到源端的子集的話，尤其需要注意。其他類型其他諸如臨時(shí)表、虛擬列、序列、視圖、存儲(chǔ)過程、函數(shù)、觸發(fā)器，索引等。這些在源端與目標(biāo)端往往在實(shí)現(xiàn)上存在較大差異，主要注意甄別并解決。這也是對象遷移階段，工作量最大的部分。如部分確實(shí)無法對應(yīng)，可考慮在應(yīng)用端實(shí)現(xiàn)類似的邏輯。數(shù)據(jù)遷移數(shù)據(jù)遷移包括全量和增量數(shù)據(jù)遷移。具體方法可參照之前說明。這里重點(diǎn)談下遷移之后的數(shù)據(jù)校驗(yàn)問題，在完成新數(shù)據(jù)平臺(tái)的搭建后，一般會(huì)和原有的數(shù)據(jù)平臺(tái)并行運(yùn)行一段時(shí)間，一方面是為了和原有平臺(tái)進(jìn)行業(yè)務(wù)和數(shù)據(jù)的比對，確保業(yè)務(wù)的正確性和連續(xù)性；另一方面，應(yīng)用改造遷移是一個(gè)循序漸進(jìn)的過程，在所有應(yīng)用遷移完成前，原有數(shù)據(jù)平臺(tái)還是要承擔(dān)正常的業(yè)務(wù)訪問。一般的做法是通過類似灰度發(fā)布的過程，開始的時(shí)候同時(shí)往兩個(gè)平臺(tái)寫入數(shù)據(jù)，但只有原有數(shù)據(jù)平臺(tái)對外提供業(yè)務(wù)訪問，每天通過數(shù)據(jù)校驗(yàn)作業(yè)，比較兩個(gè)平臺(tái)的數(shù)據(jù)一致性。經(jīng)過一段時(shí)間，確認(rèn)數(shù)據(jù)沒有問題后，再把對外訪問的流量切換到新的數(shù)據(jù)平臺(tái)，再經(jīng)過一段時(shí)間撤除原有平臺(tái)上的作業(yè)。對比方案可有多種：比較簡單的如對比數(shù)據(jù)量，即分別統(tǒng)計(jì)出數(shù)據(jù)表的條數(shù)，然后進(jìn)行比對。如果條數(shù)匹配，就認(rèn)為兩邊數(shù)據(jù)是一致的。這種方法的優(yōu)點(diǎn)是效率很高，缺點(diǎn)是不能完全保證數(shù)據(jù)的一致性。也可以采取對比數(shù)據(jù)條數(shù)加上關(guān)鍵字段校驗(yàn)，但需要提前定義出關(guān)鍵字段。也可以采取對全表做md5的