如何讓xtrabackup恢復(fù)速度提升20倍？

簡(jiǎn)介

??Xtrabackup是由percona開(kāi)源的免費(fèi)數(shù)據(jù)庫(kù)熱備份軟件，它能對(duì)InnoDB數(shù)據(jù)庫(kù)和XtraDB存儲(chǔ)引擎數(shù)據(jù)庫(kù)進(jìn)行非阻塞的備份，其具備以下一些優(yōu)點(diǎn)：
??1）備份速度快，物理備份可靠
??2）備份過(guò)程不會(huì)打斷正在執(zhí)行的事務(wù)
??3）能夠基于壓縮等功能節(jié)約磁盤空間和流量
??4）自動(dòng)備份校驗(yàn)
??5）還原速度快
??6）可以流傳將備份傳輸?shù)搅硗庖慌_(tái)機(jī)器上
??7）在不增加服務(wù)器負(fù)載的情況備份數(shù)據(jù)
??Xtrabackup熱備和恢復(fù)原理如下圖所示：

??

備份開(kāi)始時(shí)首先會(huì)開(kāi)啟一個(gè)后臺(tái)檢測(cè)進(jìn)程，實(shí)時(shí)檢測(cè)mysql redo的變化，一旦發(fā)現(xiàn)redo中有新的日志寫(xiě)入，立刻將日志記入后臺(tái)日志文件xtrabackup_log中。之后復(fù)制innodb的數(shù)據(jù)文件和系統(tǒng)表空間文件ibdata1，待復(fù)制結(jié)束后，執(zhí)行flush tables with read lock操作，復(fù)制.frm，MYI，MYD，等文件，最后會(huì)發(fā)出unlock tables，停止xtrabackup_log。
??恢復(fù)階段則啟動(dòng)xtrabackup內(nèi)嵌的innodb實(shí)例，回放xtrabackup日志xtrabackup_log，將提交的事務(wù)信息變更應(yīng)用到innodb數(shù)據(jù)/表空間，同時(shí)回滾未提交的事務(wù)(這一過(guò)程類似innodb的實(shí)例恢復(fù)）。如圖所示：

??Xtrabackup的增量備份過(guò)程和全量類似，只針對(duì)增量備份過(guò)程中的”增量”進(jìn)行處理，主要是相對(duì)innodb而言，對(duì)myisam和其他存儲(chǔ)引擎而言，它仍然是全量備份。
??從備份恢復(fù)的流程上看，備份過(guò)程主要受拷貝文件和日志生成速度影響，即和磁盤IO、網(wǎng)絡(luò)以及系統(tǒng)壓力有關(guān)；恢復(fù)過(guò)程則主要和IO、并發(fā)控制相關(guān)，本文下面將主要討論Xtrabackup恢復(fù)階段的優(yōu)化。

現(xiàn)狀

??Xtrabackup的恢復(fù)過(guò)程實(shí)則是調(diào)用內(nèi)嵌innodb的恢復(fù)邏輯來(lái)實(shí)現(xiàn)的（修改了一些參數(shù)的默認(rèn)值，如恢復(fù)時(shí)buffer pool緩存頁(yè)面數(shù)目），而innodb的恢復(fù)一直以來(lái)都不是那么的高效，社區(qū)也有很多innodb崩潰恢復(fù)流程的優(yōu)化方案。
??在實(shí)際生產(chǎn)環(huán)境中，動(dòng)輒上T的數(shù)據(jù)在使用Xtrabackup進(jìn)行熱備時(shí)通常要產(chǎn)生幾十G甚至更大的日志文件，受限于備份恢復(fù)虛擬機(jī)的配置，這樣的備份在恢復(fù)時(shí)往往需要數(shù)個(gè)小時(shí)，平均恢復(fù)速度僅為1-4M/s（熱數(shù)據(jù)分布相關(guān)），這樣的速度給現(xiàn)網(wǎng)實(shí)例的運(yùn)維造成了很大的麻煩。

問(wèn)題

??通常情況下，InnoDB的恢復(fù)過(guò)程中的內(nèi)存分配類型為MEM_HEAP_BUFFER，即在buffer pool中開(kāi)辟一段內(nèi)存用于存放日志記錄，當(dāng)需要恢復(fù)的日志文件很大時(shí)，可能存在內(nèi)存不足的情況，根據(jù)內(nèi)存是否充足把日志的處理分為兩種方式：
??1、開(kāi)辟的內(nèi)存足夠所有保存日志記錄??

??在內(nèi)存足夠的情況下，日志的解析和回放是串行的，而日志的回放是并行的，可能參與的線程包括主線程以及各個(gè)IO線程，極端情況下可能會(huì)有l(wèi)og_checkpoint線程以及其他工作線程。
??2、開(kāi)辟的內(nèi)存不足以保存所有的日志記錄??

??在內(nèi)存不足的情況下，日志解析需要進(jìn)行兩輪，第一輪解析到某個(gè)lsn之后發(fā)現(xiàn)內(nèi)存不足，后續(xù)的解析將放棄保存log record到hash table，直到解析完所有日志，最后清空這一輪生成的hash table，第一輪留給下一輪解析的遺產(chǎn)是所有需要打開(kāi)tablespace的信息和所有DDL相關(guān)信息，用于恢復(fù)開(kāi)始時(shí)的tablespace構(gòu)建；第二輪在發(fā)現(xiàn)內(nèi)存不足時(shí)，把已經(jīng)解析的日志全部應(yīng)用到頁(yè)面上，此時(shí)ibuf的merge是被禁止的（不能產(chǎn)生新的日志），這就需要在應(yīng)用完日志之后將所有臟頁(yè)刷盤，并失效buffer pool中的所有頁(yè)面，最后清空hash table，進(jìn)行后續(xù)日志的解析和回放，剩余邏輯和1相同。
??從實(shí)際情況看，整體日志恢復(fù)速度較慢，平均1-4M每秒，對(duì)于數(shù)百兆的崩潰恢復(fù)以及更大的備份日志恢復(fù)來(lái)說(shuō)，這樣的速度遠(yuǎn)遠(yuǎn)不夠。
??從以上分析來(lái)看，日志解析回放的恢復(fù)過(guò)程存在以下幾個(gè)可以優(yōu)化的地方：
??1、日志的解析
??2、日志內(nèi)存不足時(shí)的page flush
??3、日志解析和回放的并行

方案

日志解析

??log record中沒(méi)有日志長(zhǎng)度信息，由于通常情況下日志是格式化的，解析日志文件推進(jìn)的過(guò)程中需要使用簡(jiǎn)單的元數(shù)據(jù)結(jié)構(gòu)體傳入到處理函數(shù)中，從而計(jì)算單條日志的邊界，恢復(fù)的過(guò)程就是從last checkpoint lsn逐條推進(jìn)到?jīng)]有合法日志為止，這種元數(shù)據(jù)結(jié)構(gòu)實(shí)則為dict_index_t和dict_table_t結(jié)構(gòu)，日志解析和回放過(guò)程中都需要使用這種數(shù)據(jù)結(jié)構(gòu)，InnoDB的對(duì)它們的處理比較粗放，每條log record解析和回放都需要malloc和free以上一對(duì)結(jié)構(gòu)。
??在MySQL社區(qū)這兩個(gè)問(wèn)題已經(jīng)被提出，同時(shí)也提出了解決方案，如：
??1、對(duì)應(yīng)(Bug#82937)，解決方案為在log record header中增加長(zhǎng)度信息，如下圖所示：?

?

??如此，log record的邊界依靠length即可求到，省去大量元數(shù)據(jù)結(jié)構(gòu)的malloc和free，以及解析日志格式的函數(shù)調(diào)用，這一優(yōu)化可提升解析性能60%。
??2、對(duì)應(yīng)(Bug#82176)，log record在回放時(shí)確實(shí)需要元數(shù)據(jù)結(jié)構(gòu)，但需要的信息遠(yuǎn)遠(yuǎn)少于Runtime，根據(jù)分析，相同列數(shù)的表可以共享此數(shù)據(jù)結(jié)構(gòu)，在使用前重新初始化一些屬性即可，這樣就可以通過(guò)引入元數(shù)據(jù)cache來(lái)減少不必要的malloc和free。產(chǎn)品實(shí)測(cè)中，cache對(duì)單線程解析有30%+的提升，同樣社區(qū)也有阿里團(tuán)隊(duì)類似的優(yōu)化貢獻(xiàn)。
??但從解析角度出發(fā)，優(yōu)化前單核速度可以達(dá)到60-80M/s，優(yōu)化后可以達(dá)到120-160M/s，絕對(duì)速度已經(jīng)相當(dāng)可觀。
??以innodb5.6的恢復(fù)為基準(zhǔn)，通常情況下日志文件要被掃描三遍，即解析三次，即便有120M/s的速度，重復(fù)的掃描也浪費(fèi)了一部分的時(shí)間，如果對(duì)日志解析速度有更高的要求，為了追求更高的解析速度，可以引入多線程并行解析，而能否并行解析的關(guān)鍵在于日志如何有效的切分成若干個(gè)完整的分片。
??并行解析的可行性建立在能否在以LOG BLOCK組織的連續(xù)的日志文件中劃分出完整的日志片段這個(gè)問(wèn)題上。InnoDB日志解析的預(yù)讀緩沖區(qū)為RECV_SCAN_SIZE（64K），其實(shí)也是分次讀取和解析的，但其能通過(guò)邊界計(jì)算處理跨越64K邊界的日志記錄，跨越邊界的整個(gè)日志記錄將在下一個(gè)64K中全部讀取，相當(dāng)于下一次讀取的日志塊和上一次是有重疊的。
??由此，我們按照固定大?。↙OG BLOCK的整數(shù)倍，如10M）切分日志塊，第一個(gè)分片的第一個(gè)BLOCK的起始位置通過(guò)checkpoint lsn定位，其余分片的第一個(gè)BLOCK起始位置通過(guò)LOG_BLOCK_FIRST_REC_GROUP來(lái)確定，如果某個(gè)分片內(nèi)日志不能完整結(jié)束，則向下一個(gè)分片移動(dòng)，直到解析出完整的日志為止，分片的移動(dòng)可能導(dǎo)致兩個(gè)分片解析到同一個(gè)log record，由于日志回放是冪等的，所以重復(fù)的日志記錄只要按照l(shuí)sn有序，多次回放不影響正確性。日志文件的分片窗口如下圖所示：??

??應(yīng)用并行解析后的恢復(fù)流程將減少大量的解析時(shí)間，如下圖所示：??

Page Flush

??以上分析中，我們發(fā)現(xiàn)當(dāng)分配的buffer pool不足以放下所有日志記錄時(shí)（大實(shí)例絕大多數(shù)會(huì)發(fā)生），日志就會(huì)被解析多次，然后分批的進(jìn)行回放，每次回放完成的頁(yè)面由于不能執(zhí)行ibuf merge，只能觸發(fā)page cleaner全部刷到磁盤，而且當(dāng)熱頁(yè)面比較分散時(shí)，每一輪的回放涉及的頁(yè)面遠(yuǎn)遠(yuǎn)超過(guò)Xtrabackup默認(rèn)的512個(gè)頁(yè)面的buffer，這就導(dǎo)致產(chǎn)生了大量single page的淘汰，每個(gè)頁(yè)面都需要調(diào)用一次fil_flush（fsync），形成嚴(yán)重的性能瓶頸，大實(shí)例尤為嚴(yán)重。
??結(jié)合現(xiàn)網(wǎng)Xtrabackup進(jìn)行熱備的方式，發(fā)現(xiàn)目前整個(gè)備份恢復(fù)過(guò)程其實(shí)是整體完成的（原子的），一次備份（全量或增量）只有完整的恢復(fù)完才算成功，如此就可以在page flush上進(jìn)行比較巧妙的優(yōu)化，即將恢復(fù)階段所有的page flush改為只寫(xiě)文件緩存，而不調(diào)用fli_flush，fsync操作交給操作系統(tǒng)批量調(diào)度，換句話說(shuō)就是將同步的刷臟變成了異步，整個(gè)恢復(fù)完成時(shí)fil_close將會(huì)把所有未落盤的臟頁(yè)全都刷下去，頁(yè)面淘汰不再成為瓶頸，每一輪的回放速度將大大提升。

解析回放并行

??如下圖所示，日志的解析和回放并行在InnoDB中的大致方案，不同與串行方式，解析過(guò)程不再獨(dú)立存在，而是與回放線程（寫(xiě)新日志）、IO線程以及checkpoint線程并發(fā)，這樣的并發(fā)受限于InnoDB的一些現(xiàn)有機(jī)制，如內(nèi)存管理、刷臟機(jī)制、tablespace以及checkpoint機(jī)制等，下面將逐一展開(kāi)分析：??

??1、內(nèi)存管理
??InnoDB恢復(fù)階段所需內(nèi)存申請(qǐng)類型為MEM_HEAP_BUFFER，從buffer pool中劃分一塊內(nèi)存，大小有限，因此存在先前提到的兩階段解析。由于MEM_HEAP_BUFFER類型的特點(diǎn)，多次申請(qǐng)，統(tǒng)一釋放，如果和回放并行，當(dāng)內(nèi)存達(dá)到上限時(shí)，解析不得不停止下來(lái)，等待所有日志apply結(jié)束，回收內(nèi)存之后再繼續(xù)進(jìn)行解析。
可以將日志解析和回放理解成生產(chǎn)者和消費(fèi)者，日志回放為消費(fèi)者，回放過(guò)后的日志記錄即可回收，將內(nèi)存類型設(shè)置為MEM_HEAP_DYNAMIC，每條日志記錄解析時(shí)malloc自己的內(nèi)存，回放結(jié)束后將其釋放，因?yàn)榛胤攀遣l(fā)的，總體來(lái)說(shuō)內(nèi)存是大體穩(wěn)定的。
??2、新日志生成
??InnoDB通過(guò)恢復(fù)階段依然通過(guò)log_sys管理日志，ibuf merge產(chǎn)生的日志需要寫(xiě)在同一個(gè)日志文件中，但通常情況下，解析線程不結(jié)束解析過(guò)程是無(wú)法得到系統(tǒng)持久化lsn的，因此新日志的起始lsn以及寫(xiě)入日志文件的offset無(wú)法確定，從而解析階段產(chǎn)生新日志通常是不可能實(shí)現(xiàn)的。
??如果在恢復(fù)初期不能得到持久化lsn，將會(huì)對(duì)生成新日志形成障礙。對(duì)于InnoDB的恢復(fù)，也有例外存在，如InnoDB如果需要兩階段解析的話，第一階段結(jié)束后系統(tǒng)持久化lsn其實(shí)已經(jīng)可以確定；對(duì)于Xtrabackup來(lái)說(shuō)，拷貝得到的日志在拷貝結(jié)束時(shí)是可以確定結(jié)束lsn（即最終持久化的lsn）。因此，對(duì)于Xtrabackup的恢復(fù)而言，不存在生成新日志的障礙。
??最后，InnoDB恢復(fù)階段log_sys中某些屬性也在恢復(fù)邏輯中被使用，如buffer等，和寫(xiě)日志邏輯是沖突的，需要將log_sys中有沖突的屬性轉(zhuǎn)移到recv_sys中實(shí)現(xiàn)。
??3、刷臟機(jī)制和增量checkpoint
??InnoDB使用flush list管理臟頁(yè)面，臟頁(yè)面在flush list中以首次變臟時(shí)的lsn為順序排序，每當(dāng)臟頁(yè)被刷盤之后，就從flush list中將其移除，增量checkpoint機(jī)制定時(shí)掃描flush list中最小的lsn，以此為checkpoint lsn進(jìn)行打點(diǎn)，選取打點(diǎn)的lsn必須滿足“在flush list中，小于這個(gè)lsn的所有修改涉及的頁(yè)面都在這個(gè)lsn所屬頁(yè)面之前”的原則，這個(gè)原則直接依賴于頁(yè)面按照首次變臟lsn有序。
??在InnoDB的恢復(fù)中，頁(yè)面在flush list中的順序不是在解析日志的時(shí)候維護(hù)的，而是在具體某個(gè)頁(yè)面回放完日志之后才確定的（頁(yè)面回放完日志之后插入到flush list），由于多線程回放，主線程按照hash table的桶順序回放，或者按需回放（讀取某個(gè)頁(yè)面），因此flush list中臟頁(yè)的順序并不完全按照首次修改有序，直到所有的頁(yè)面都回放完日志，最終的flush list的狀態(tài)才是完全正確的狀態(tài)，因此，在InnoDB的恢復(fù)中，log_checkpoint才是在所有頁(yè)面全部回放完日志記錄之后進(jìn)行的。
??解析和回放并行勢(shì)必會(huì)產(chǎn)生新的日志，而日志緩沖區(qū)和日志文件大小是有限的，如果新日志的產(chǎn)生沒(méi)有足夠的空間，此時(shí)還不能做log checkpoint，那么恢復(fù)過(guò)程可能會(huì)卡死；解析和回放并行產(chǎn)生的臟頁(yè)，在IO允許的情況下，及時(shí)持久化并推進(jìn)checkpoint，避免恢復(fù)過(guò)程中異常退出之后再次重新恢復(fù)。
??能否在解析日志時(shí)進(jìn)行checkpoint，根本問(wèn)題是如何時(shí)刻維護(hù)flush list的順序。頁(yè)面的修改順序就是其在日志中出現(xiàn)的順序，其順序和首次修改完全等價(jià)，因此可以在日志解析時(shí)peek頁(yè)面是否在buffer pool中，如果不在則將其load上來(lái)，此時(shí)不必實(shí)際讀取頁(yè)面，只需要在flush list中占一個(gè)位置即可，如果從flush list中刷臟頁(yè)時(shí)頁(yè)面還沒(méi)有l(wèi)oad上來(lái)，那么就必須發(fā)生一次同步IO。通過(guò)這種方式，可以在解析日志時(shí)一直維護(hù)flush list的順序，由此解決恢復(fù)階段checkpoint的限制。
??4、Tablespace
??InnoDB恢復(fù)時(shí)的fil_space信息從日志記錄中類型為MLOG_FILE_NAME的日志獲得，因?yàn)榛謴?fù)階段SYS_TABLESPACE系統(tǒng)表中的記錄可能是不完整的，MLOG_FILE_NAME類型的記錄在每次tablespace首次變臟或者checkpoint的時(shí)候?qū)懭肴罩?，為的是在恢?fù)時(shí)能夠打開(kāi)所有需要的tablespace（MySQL 5.7.5引入的優(yōu)化，先前的版本是打開(kāi)所有ibd文件來(lái)load tablespace）。
??如下圖所示，當(dāng)最后一次checkpoint發(fā)生在lsn為1000時(shí)，T1表在checkpoint之后仍然有修改，而T1表的MLOG_FILE_NAME日志在寫(xiě)MLOG_CHECKPOINT之前，在T1的最后一條日志之后。如果解析和回放并發(fā)，當(dāng)T1的最后一條日志需要被重放時(shí)，T1的FIL_NAME日志沒(méi)有解析到，它的tablespace就不會(huì)load，此時(shí)重放以及后續(xù)的IO可能出現(xiàn)問(wèn)題；系統(tǒng)表有可能還沒(méi)有恢復(fù)，所以此時(shí)通過(guò)dict_load的方式也是不可行的。??

??此外，如果某個(gè)表在checkpoint之后存在修改，并且在后續(xù)的操作中被drop，如下圖所示，那么恢復(fù)過(guò)程可以忽略這個(gè)表的日志，因?yàn)椴恍枰膊豢赡芑謴?fù)（物理文件已經(jīng)刪除，沒(méi)有tablespace），這個(gè)過(guò)程是在recv_init_crash_recovery_spaces()中完成的，它要求先將日志全部解析，生成完整的FIL_NAME表，然后統(tǒng)籌那些表不需要恢復(fù)。?

?

??如果解析和回放并行，Tablespace的Load可以在解析日志前通過(guò)掃描所有ibd文件，load所有已存在的tablespace方式完成；或者將當(dāng)前系統(tǒng)表中已存在的表通過(guò)dict_load的方式全部加載，即使此時(shí)的tablespace是不完整的。此外，對(duì)于刪掉或者truncate掉的表，如果在回放日志時(shí)fil_space不存在，或者page no超過(guò)tablespace的size，則不回放相關(guān)日志記錄。

實(shí)施

??從以上可行性分析來(lái)看，解析和回放在InnoDB中從理論上是可以實(shí)現(xiàn)并行的，但需要一些關(guān)鍵機(jī)制的適配，涉及內(nèi)容比較多，復(fù)雜度高，結(jié)合性能收益，我們將對(duì)實(shí)際實(shí)施的優(yōu)化進(jìn)行取舍。
??從收益來(lái)看，假設(shè)日志解析總時(shí)間為Xa，回放總時(shí)間為(10-X)a，在引入dict_index cache以及并行解析日志之后，整個(gè)解析和回放的時(shí)間會(huì)提升10/(10-(1-0.7/N)*X))倍，其中0.7為dict_index cache單線程提升的效果，N為并發(fā)解析線程數(shù)，由公式可以看到，當(dāng)解析時(shí)間占比比較大時(shí)，增加并發(fā)解析線程數(shù)，就能大大提升恢復(fù)效率；如果回放時(shí)間占比大時(shí)，即使將解析和回放并行，收益也是很有限的。
??綜上，鑒于解析和回放并行的高復(fù)雜度和有限的收益以及解析和回放代價(jià)占比，目前恢復(fù)的優(yōu)化方案主要針對(duì)單線程的解析優(yōu)化和頁(yè)面的刷盤優(yōu)化，具體實(shí)施方案如下：
??1、dict_index cache
??對(duì)每一個(gè)獨(dú)立的解析線程，增加線程級(jí)cache（避免不必要的鎖開(kāi)銷），cache的搜索key為列數(shù)，兩個(gè)列數(shù)相同的表共享一對(duì)dict_index和dict_table結(jié)構(gòu)，使用前需要重新初始化結(jié)構(gòu)上的一些字段。
??對(duì)于主線程、若干個(gè)IO線程以及可能執(zhí)行回放任務(wù)的checkpoint線程，也增加線程級(jí)cache，用于回放階段的優(yōu)化
??2、控制多次解析
??首先將innodb 5.6中最多掃描日志三次的機(jī)制改為最多掃描兩次，其實(shí)是消除mlog_checkpoint的作用；提供配置參數(shù)，配置在熱備產(chǎn)生大量日志的情況下，跳過(guò)第一輪log record加入log hash table的操作，使得第一輪掃描變?yōu)榭焖贅?gòu)造tablespace，對(duì)高負(fù)載的小實(shí)例熱備有一些作用，參考生成日志文件大小和buffer pool的大小進(jìn)行配置。
??3、延遲刷臟
??提供配置參數(shù)，配置在恢復(fù)階段臟頁(yè)刷盤方式，實(shí)施異步刷臟。

測(cè)試

環(huán)境

??開(kāi)發(fā)機(jī)：Dev-VD2??

數(shù)據(jù)庫(kù)

??數(shù)據(jù)庫(kù)參數(shù)
??port=3306
??max_connections=100
??innodb_buffer_pool_size=4G
??innodb_buffer_pool_instances=2
??innodb_file_per_table=1
??innodb_flush_log_at_trx_commit=0
??innodb_log_buffer_size=512M
??innodb_log_file_size=1G

測(cè)試

??目前，所有5.6版本（之前）日志解析都需要默認(rèn)進(jìn)行三次，結(jié)合Xtrabackup自身的特點(diǎn)，兩次完全足夠，本章節(jié)就不再對(duì)比解析三次的測(cè)試。（單位ms）

?
??

以上測(cè)試均是小實(shí)例、虛擬機(jī)上的測(cè)試對(duì)比，這些優(yōu)化在不同場(chǎng)景下提升幅度各有不同，大部分在30%-75%之間，受系統(tǒng)負(fù)載，IO，熱數(shù)據(jù)分布等因素影響；現(xiàn)網(wǎng)中一個(gè)2T的實(shí)例，某次熱備產(chǎn)生20G的日志，優(yōu)化后恢復(fù)時(shí)間從原先的4小時(shí)降低到10分鐘，恢復(fù)速度大幅提升了20余倍。

演進(jìn)

??針對(duì)不同場(chǎng)景的實(shí)例，可以進(jìn)一步的深度優(yōu)化，如前所述的并行解析、日志格式引入長(zhǎng)度信息（需考慮兼容性問(wèn)題）、結(jié)合Xtrabackup自身tablespace處理特點(diǎn)優(yōu)化tablespace的構(gòu)建等；InnoDB恢復(fù)時(shí)日志相關(guān)的內(nèi)存管理比較粗放，也有優(yōu)化的空間；此外，恢復(fù)階段的鎖如recv_sys的mutex、fli_system的mutex、flush list的mutex以及buffer pool的mutex都有一定的優(yōu)化空間。
??不管采用何種方式優(yōu)化，當(dāng)實(shí)例和日志很大時(shí)，解析優(yōu)化所帶來(lái)的效果將會(huì)越來(lái)越小，其在整個(gè)恢復(fù)過(guò)程中已不再成為瓶頸，瓶頸一般都會(huì)轉(zhuǎn)移到IO上來(lái)，因此后續(xù)的優(yōu)化需要結(jié)合特定場(chǎng)景具體分析，有的放矢地進(jìn)行針對(duì)性的優(yōu)化。