對MySQL8做了一個大緻的學習彙總。第一個版本的大綱如下圖。
MySQL8大綱(v1.0.0)
認識MySQL
定義
- 資料庫：資料庫是資料檔案和其他檔案的集合。
- 資料庫執行個體：資料庫執行個體是由程序和記憶體組成。資料庫執行個體是真正操作資料庫檔案。
- MySQL是一個單程序多線程架構的資料庫。
架構體系
- SQL執行分層
- 連接配接器->查詢緩存->分析器->優化器->執行器->存儲引擎
- 連接配接器
- 查詢緩存(8.0版本已經棄用)
- 分析器
- 優化器
- 執行器
- 存儲引擎
- 分層内容
- 執行順序
- 體系結構
- 連接配接層
- SQL層
- 網絡通信
- 線程處理
- 使用者密碼認證
- 查詢緩存
- 解析器
- 優化器
- 執行器
- 權限判斷
- 預處理
- 定義：存儲引擎是以插件式的方式運作，主要用于資料存戶與檢索。可以根據MySQL内部的接口實作自定義存儲引擎。
- 分類
- Memory
- ARCHIVE
- NDB
- 資料檔案存放記憶體，預設使用哈希索引、隻支援表鎖、不支援TEXT和BLOB類型資料、varchar按照定長方式存儲
- 資料壓縮存儲、隻支援INNSERT和SELECT操作
- 資料全部存放記憶體
- MyISAM
- InnoDB
- Maria
- 支援表鎖、全文索引、GEO、緩存區隻存儲索引内容
- 支出表鎖、行鎖、MVVC、事務、自适應哈希索引、
- 支援緩存資料和索引檔案、支援行鎖、支援MVVC、支援事務和非事務；旨在替代MyISAM
- 官方存儲引擎
- 第三方存儲引擎
- 存儲引擎層
- 服務層
- 檔案
- MYD
- MYI
- frm
- ibd
優勢
- 跨平台
- 移植性強
- 開源版和企業版
- 成本低
InnoDB存儲引擎
認識InnoDB
- InnoDB存儲引擎是MySQL第一個支援完整ACID事務的存儲引擎，它以插件是的方式在MySQL5.5版本開始作為預設的存儲引擎。
- InnoDB存儲引擎支援行鎖、MVCC、外鍵和提供一緻性非鎖定讀等特點。
體系架構
- InnoDB存儲引擎由多個記憶體塊組成，這些記憶體組成了一個大的記憶體池。
- 記憶體池
- 作用
- 分類
- 重新整理記憶體中的資料。
- 已修改的資料檔案重新整理到磁盤中。
- 異常情況下，資料復原到正常情況。
- 負責髒頁的重新整理。
- 事務送出之後，負責回收已經使用并配置設定的undo頁。
- 負責IO請求回調，進行資料的讀寫操作。
- 核心線程，将緩沖池的資料重新整理到磁盤中，保證資料的一緻性、髒頁的重新整理、合并插入緩沖池、undo頁回收等。
- Master 線程
- IO 線程
- Purge 線程
- Page Cleaner 線程
- 線程
記憶體
- 緩沖池
- 配置緩沖區大小：innodb_buffer_pool_size
- 作用：資料從記憶體中去讀寫，以提高并發能力。通過CheckPoint機制重新整理到磁盤中。
- 内容：索引頁、資料頁、undo頁、鎖、插入緩沖、自适應hash、資料字典等資訊。
- 在1.0.x版本開始，允許建立多個緩沖池執行個體。降低了資料庫内部的資源競争，提高資料并發能力。
- 配置項
- 重做日志緩沖池
- 配置緩沖區大小：innodb_log_buffer_size
- Master線程每一秒将緩沖區的日志寫入到重做日志檔案。
- 事務送出時将緩沖區的日志寫入到重做日志檔案。
- 當緩沖區日志可用空間小于1/2時，觸發寫入重做日志檔案。
- 作用：先将重做日志寫入到重做日志緩沖區，在根據一定頻率(一般是1s)将緩沖區的日志寫入到緩沖日志檔案中。
- 觸發機制
- 配置項
- 額外記憶體池
- 記憶體管理
- 定義：緩沖池按照LRU算法，對緩存池中的頁進行排序。最頻繁使用的放在LRU清單最前面，使用最少的放在LRU清單最後面。
- 觸發機制：當緩沖池不能存放新的頁時，就會觸發LRU機制。
- LRU算法優化：InnoDB對LRU算法做了一定的優化。當有新寫入頁時，并不是直接寫入頁的尾部，而是插入到midpoint位置。midpoint表示新寫的頁插入位置。可以通過innodb_old_blocks_pct進行配置。在該值的前面就成為new清單，後面則成為old位置。new清單表示最為活躍的熱點資料。
- 為什麼InnoDB需要對LRU算法進行優化，而不是直接使用LRU算法呢？
- InnoDB對LRU算法進行了優化，優化了哪些内容？
- LRU List
- Free List
- Flush List
庫與表操作
資料庫檔案
- 配置檔案
- 日志檔案
- 錯誤日志檔案
- 全量日志檔案
- 慢查詢日志檔案
- 二進制日志檔案(DML)
- 審計日志檔案
- 中繼日志檔案
- 事務日志(undo log和redo log)
- PID 檔案
- Socket 檔案
- 表結構檔案
- 存儲引擎檔案
- redo 日志(實體日志)
- undo 日志(邏輯日志)
資料庫與表
- 字元集
- 資料庫
- create database 資料庫名稱
- rename database 資料庫名 to 新資料庫名
- 資料表
- create table 資料表名 (表字段) engine=表存儲引擎
- alter table 資料表名 rename to 新資料表名
- rename table 資料表名 to 新資料表名
- alter table 資料表名稱 操作
- 資料類型
- datetime、timestamp、year、date、time等
- char、varchar、text、blob等
- int、double、decimal等
- 數值類型
- 字元串類型
- 時間類型
- JSON類型
- 枚舉類型
- 查詢
- 等值查詢
- 不等值查詢
- 自連接配接查詢
- 交叉連接配接
- 内連接配接
- 外連接配接
- 聯合查詢
- 嵌套查詢
進階特性
事務
- 事務定義
- 一組DML語句的集合
- 事務分類
- 扁平化事務
- 帶有儲存點扁平化事務
- 鍊式事務
- 嵌套事務
- 分布式事務
- 存儲引擎
- InnoDB
- 送出方式
- 全部復原
- 全部送出
- 送出點(savepoint)
- 顯式送出
- 隐式送出
- 自動送出(預設情況)
- ACID
- 未送出讀
- 送出讀
- 可重複讀(讀的是目前事務開始的資料)
- 串行(資料行加表級共享鎖)
- 髒讀
- 幻讀(update/delete)
- 不可重複讀(insert)
- 幻讀
- 不可重複度
- 原子性(Atomicity)
- 一緻性(Consistency)
- 隔離性(Isolation)
- 持久性(Durability)
- truncate 與 delete 差別
- truncate清空表主鍵，從 0 開始。
- truncate 不可復原，delete 支援復原。
- 删除資料
- 相同點
- 不同點
- 分布式事務
- MVVC
- 1.DB_TRX_ID：用來辨別最近一次對本行記錄做修改的事務的辨別符，即最後一次修改本行記錄的事務id。delete操作在内部來看是一次update操作，更新行中的删除辨別位DELELE_BIT。
- 2.DB_ROLL_PTR：指向目前資料的undo log記錄，復原資料通過這個指針來尋找記錄被更新之前的内容資訊。
- 3.DB_ROW_ID：包含一個随着新行插入而單調遞增的行ID, 當由innodb自動産生聚集索引時，聚集索引會包括這個行ID的值，否則這個行ID不會出現在任何索引中。
- 4.DELELE_BIT：用于辨別該記錄是否被删除。
- innodb存儲引擎中，每行資料都包含了一些隐藏字段：DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR和DELETE_BIT。
- 多版本并發控制簡單的說就是目前事務隻能看見已經送出的資料記錄，看不到正在修改的資料記錄。是以我們隻要弄清楚那些事務對于目前事務是已經送出的，那些事務對于目前事務是活躍的。
- 實作原理
- 相關字段
視圖
存儲過程
觸發器
鎖
鎖介紹
- (存儲引擎)表鎖和行鎖。InnoDB支援表鎖和行鎖，MyISAM隻支援表鎖。
- 定義：鎖是防止并發式通路同一資料，導緻資料不能達到一緻性的資料保護機制。
鎖類型
- 讀鎖
-
文法
-- 寫鎖 select * from tableName where id = ? for update; -- 讀鎖 select * from tableName where id = ? in share model;
- 行鎖種類
- InnoDB添加鎖，是添加到索引列。如果不是則會發生意向鎖。
- 定義：根據鎖的顆粒度劃分，意向鎖是InnoDB中的表鎖形式。意向鎖會鎖住庫中的表、資料頁，然後在鎖住資料行。
- 定義：在對某一行添加鎖時，其他的線程是不能對該行進行update、delete操作。
- 定義：當InnoDB掃描索引時，會對選中的索引添加一個寫鎖。在對索引記錄的兩邊添加一個間隙鎖鎖。
- 在RR事務隔離級别情況下，如果發生間隙鎖。當時加鎖的線程執行了事務的送出操作，在等待鎖的線程中是可以檢視到修改行對應的資料變化。
- Next-key Locks
- 讀鎖
-
文法
啟用鎖
LOCK TABLES table_name [READ | WRITE];
UNLOCK TABLES;
- 鎖競争
- 1.加鎖的session可以執行插入、删除、修改和查詢。
- 0:不支援插入。
- 2:強制支援在表的末尾插入新資料。
- 配置項(concurrent_insert)
- 行鎖(InnoDB)
- 目前session對某一行加鎖，沒有索引的情況下。會自動進行鎖更新，将行鎖更新為表鎖。其他的session将無法做加鎖、查詢、更新、建立和删除操作。
- 目前session對某一行加鎖，其他的session不能對目前加鎖的行進行加鎖、更新和删除，但是可以進行查詢。
- 加鎖的session隻能執行查詢，不能進行更新、插入和删除。
表鎖與行鎖差別(分析角度)
- 顆粒度
- 開銷
- 并發程度
常見問題
- InnoDB
- 自動監控鎖逾時
- 寫優先權大于讀
- 鎖等待
鎖監控
- INNODB_TRX(表)
- INNODB_LOCK_WAITS(表)
- infomation-schema(庫)
索引
- 索引定義
- 索引是一種為了快速檢索資料的資料結構
- 索引檢索方式
- 索引檢索快，是因為選擇了合适的資料結構。
- 索引檢索時，首先會去查找索引key對應的索引頁，然後把該頁的資料加載到記憶體中，然後通過在記憶體中進行篩選，得到資料的實體位址。然後根據實體位址在去磁盤中進行查找。
- 索引的優缺點
- 索引存儲在磁盤中，會占空磁盤空間。對于查詢效率來說，這一點磁盤空間不足考慮。
- 對資料的增删改，都會去維護索引。是以也有時間消耗。
- 通過索引的順序查找資料，查詢快。由原來的随機查找變為索引順序查找。
- 優點
- 缺點
- 索引分類(按照存儲引擎分類)
- myisam存儲引擎為了檢索全文的一種索引類型。主要用來查找文本中的關鍵字，而不是直接與索引中的值相比較。fulltext索引跟其它索引大不相同，它更像是一個搜尋引擎，而不是簡單的where語句的參數比對。全文索引在InnoDB1.2.x版本中也同樣支援并且具備更多的功能。
- 是一種等值檢索的索引，在innodb中是自适應的，無法人為的去設定，而是通過MySQL内部自動根據情況來設定。
- 為了存儲地理空間資料的一類索引。
- 是一種由B樹和索引通路順序演變而來的索引，也就是我們常說的一種索引類型。
- B+Tree
- 空間索引(InnoDB不支援)
- Hash索引
- 全文索引
- InnoDB存儲引擎中的索引
- 失效場景
- 使用LIKE進行模糊查找
- 使用OR進行邏輯或查找
- 使用IN進行範圍查找
- 索引列與索引列比較
- 索引列使用了表達式、函數
- 索引對應列的類型，與條件中的類型不一緻(需要注意MySQL在一些情況下回做隐式轉換。)
- 用>、<或者!=這樣的比較運算符
- 說明
- 建立索引的幾種場景
- 索引建立規範
- 索引雖然能夠幫助我們高效查詢資料。但是在做DDL操作時，索引内部需要進行維護，這也是有消耗的。是以建立索引不是越多查詢效率就越高，也不是越少越好。我們需要把我好其中的度。
- 資料量大，查詢頻繁。
- 針對條件查詢時，建立索引。
- 盡可能的使用聯合索引，而不是建立多個單列索引。
- 針對where查詢條件的字段，建立索引。
- 查詢頻率高的字段，建立索引。
- 盡可能的使用唯一索引，因為唯一索引的key是唯一的，查詢效率更快。
- 索引的名稱盡可能的短，因為索引的名稱也要占磁盤空間。
-
索引列的區分度越高越好。
例如在sex(性别)上建立索引就不是一個很好的方式。因為性别無非就是三種情況。這裡的區分度指的是索引列的值存在多種情況。
- 建立索引
- 删除索引
- 檢視索引
- alter table table_name(表名) add [primary key | uniique | index | fulltext] index_name(索引名)(column_name[長度])[asc|desc]
- create [primary key | uniique | index | fulltext] index index_name(索引名) on table_name(表名)(column_name[長度])[asc|desc]
- drop index index_name(索引名稱) on table_name(表名)
- show index form table_name(表名)
- 聚集索引
- 非聚集索引
- 差別
- InnoDB是一種索引組織表，表中的每一行資料都是按照主鍵的順序來存儲的。聚集索引正是使用表的每一個主鍵建構的一個B+Tree結構的索引。
- 聚集索引的子節點存儲的是表中的行資料。
- 說明
- 定義：以某一列的某些特點字元作為索引的字首。可以看成是普通索引的更新版。
- 适用的字段類型
- 優缺點
- text
- blob
- varchar
- 便于快速檢索資料。
- 不能使用在order by情況中。
- 不能使用在group by的情況中。
- 不能使用在覆寫索引的情況中。
- 建立的索引長度，最好是根據column_name對應的長度來确定。
- 定義:一個索引包含(覆寫)所有查詢字段的值。
- 優勢
-
舉例：
在name 字段建立了一個索引。使用如下查詢就是一個覆寫索引。select id, name from user where name = '張三'。因為 id 是一個預設的主鍵索引，而name 字段也是一個索引。在存儲的時候，會将 name 和 id 存儲到一塊。是以在查詢的時候，包含了所有的查詢字段的值。如果是select id, name, age from user where name = '張三'。就會從新回盤查找。
- 失效問題(常見)
- 1.索引的數目始終是小于資料表的數目。
- 2.順序通路，避免随機 IO(索引存儲的是有順序的)。
- 3.減少系統調用(部分存儲引擎,如 MyISAM在記憶體中存儲的是索引)，讀取資料還需要系統層面。
- 4.在 InnoDB 的聚簇索引中，可以減少二次索引開銷。
- 減少回表查詢。
- 作用
- 原因
- 沒有任何索引能覆寫到該查詢。
- 進行報錯字首的like 比較操作。
- 定義：由兩個或者兩個以上的列組成的索引集合。聯合索引要求在使用時，要遵循最左側原則(在一些統計類型的查詢中，MySQL内部優化器會存在使用索引的情況。)。
- 優缺點
- 減少資料檢索範圍。
- 必須遵循字首索引原則，夠則索引會生效。
- 沒有任何限制，就是單純的一個索引，就是為了某一列的快速檢索。
- 定義：索引列的值不能重複，但是可以為NULL。
- 文法：alter table table_name add unique(column_name)
- 唯一索引
- 普通索引
- 聯合索引
- 覆寫索引
- 字首索引
- InnoDB是一種索引組織形式的表，表都是根據主鍵順序進行排序。
- 聚集索引其實就是一種索引組織形式，索引的鍵值決定了資料行的實體存儲順序。
- 主鍵索引的葉子節點存的是整行資料。在 InnoDB 裡，主鍵索引也被稱為聚簇索引（clustered index）。
- 非主鍵索引的葉子節點内容是主鍵的值。在 InnoDB 裡，非主鍵索引也被稱為二級索引（secondary index）。
- 普通索引需要先搜尋一次索引樹，得到主鍵索引的值，然後在根據主鍵索引檢索出資料。
- 二叉樹
- 平衡二叉樹(AVL樹)
- B樹
- 索引通路順序(ISAM)
- B+Tre
- 當資料量大的時候，樹的高度大(節點多)，檢索資料同樣會很慢，導緻效率不高。
- 插入資料非常簡單，隻需要根據每一個節點的值進行大小比較，就可以确定新插入的值放在什麼位置。
- 每一個節點隻會存在兩個子節點，節點左側的值一定是小于根節點的值，節點右側的值一定是大于根節點的值。
- 特點
- 優點
- 缺點
- 由于需要保證樹節點的高度差，則資料結構内部做更新、删除和插入操作時，需要對樹的内部結構進行調整，頻繁的進行樹的左右旋轉，也會導緻執行效率低下。
- 平衡二叉樹是由二叉樹演變而來的一種資料結構，同樣也遵循二叉樹的特點；二叉樹對于樹的節點高度，要求相差不能大于1，如果大于1則會通過左右旋進行調整，保證樹的節點高度差。
- 平衡二叉樹是由于二叉樹的缺點，進行優化、演變而來的資料結構。
- 平衡二叉樹是由二叉樹演變而來的一種資料結構，同樣也遵循二叉樹的特點；二叉樹對于樹的節點高度，要求相差不能大于1，如果大于1則會通過左右旋進行調整，保證樹的節點高度差。
- 特點
- 優點
- 缺點
- B數的内部節點和葉子節點存放的都是索引的key和值。相對B+Tree占用的空間大、存儲的資料小。
- 随機通路，不屬于索引順序通路。
- 對于資料結構的更新、插入以及删除相對平衡二叉樹更加高效；一個節點上可以存在2個以上的子節點，樹的高度就可以降低，是以查詢的效率也高很多。
- 是一種自平衡的樹，能夠保持資料有序。這種資料結構能夠讓查找資料、順序通路、插入資料及删除的動作，都在對數時間内完成。
- B樹，概括來說是一個一般化的二叉查找樹（binary search tree）一個節點可以擁有2個以上的子節點。
- 與自平衡二叉查找樹不同，B樹适用于讀寫相對大的資料塊的存儲系統，例如磁盤。B樹減少定位記錄時所經曆的中間過程，進而加快存取速度。
- B樹這種資料結構可以用來描述外部存儲。這種資料結構常被應用在資料庫和檔案系統的實作上。
- 總結下來，就是在平衡二叉樹上面的一種延伸。相對平衡二叉樹内部的左旋和右旋更加高效，同時一個節點上可以存在多個子節點。
- 特點
- 優點
- 缺點
- 資料的通路是有序的，這樣可以更加快速的找到需要的資料。
- 這種算法也是MyISAM存儲引擎采用的一種算法結構
- 特點
- 優點
- 索引的存儲非常高效。
- 索引的key按照順序排列，查詢效率高。并且索引頁之間，都是通過指針連接配接起來，查找時無需額外消耗。
- B+Tree是由B樹和索引通路順序算法結合而成的。既滿足B數的特點也滿足索引通路順序的特點。
- 特點
- 優點
- 提到索引，一般會以InnoDB存儲引擎為主。該存儲引擎底層使用的是B+Tree資料結構，要了解該資料結構就需要了解其他的幾種資料結構。
- 說明
- 資料結構的演變
- 索引分類
- 索引文法
- 高效使用索引
- 索引常見問題
- hash索引
- 不能使用範圍查找。
- 不能進行比較查找。
- 不能進行排序。
- 不需要像B+tree進行逐級查找，隻需要進行一次的hash計算，就等定位到資料，檢索快。
- InnoDB存儲引擎會根據表的使用情況，自動生成hash索引，不能通過人為的幹預生成hash索引。
- 定義：通過将鍵值進行hash計算，檢索時通過過相同的hash方式進行等值查找的一種存儲政策方式。查詢效率高，時間複雜度為O1。
- 優缺點：
- 常用工具
- id
- select_type
- table
- partitions
- type
- possible_keys
- key
- key_len
- ref
- rows
- filtered
- Extra
- 查詢編号。
- subquery
- derived：包含在from子句的子查詢中的select。
- union
- union result
- 查詢類型。
- 查詢表。
- all：全盤掃描。
- index：
- range：
- ref
- eq_ref
-
const、system
null
- 查詢類型
- 查詢的key。
- 決定那個索引key查詢表。
- 索引key長度。
- 顯示key列記錄在索引查找中使用的列或者常量。
- 查找資料，讀取的行數。
- using index：使用了覆寫索引。
- using where：存儲引擎檢索行後在進行過濾。不是所有的where條件查詢都會出現。
- using temporary：使用了一個臨時表。
- using filesort：使用了外部索引排序，而不是按索引次序從表中讀取資料。排序可能是記憶體中或者硬碟中進行。
- Table
- Non_unique
- Key_name
- Seq_in_index
- Column_name
- Collation
- Cardinality
- Sub_part
- Packed
- Null
- Index_type
- Index_comment
- Comment
- 資料表名
- 非唯一索引
- 索引名稱
- 索引中該列的位置
- 索引的表字段名稱
- 列使用什麼方式存儲在索引中。值可以是A或者NUll。B+Tree的總是A。
- 如果使用的是Heap存儲引擎并且開啟hash索引，就會顯示為NULL。因為hash是根據hash桶存放索引資料，而不是通過順序存放。
- 索引中唯一值的數目的估計值。
- 如果非常小，可以考慮進行删除。
- 優化器會根據這個值來進行判斷，是否使用這個索引。
- 該值不是實時更新的，可以使用analyze table進行優化。
- 是否列的部分被索引。
- 關鍵字是否被壓縮。
- 是否索引的列含所有NULL值。
- 索引類型。
- 索引描述。
- 檢視索引(show index from table_name)
- 檢視SQL索引情況(explain select xxxx;)
- extra出現 “useing index” 則使用的是覆寫索引，隻掃碼索引的資料，而不是按照索引的順序讀取每一行，開銷小。
- 避免了排序，但是要按照索引的順序去讀取資料，則屬于磁盤随機讀，開銷大。
- 和全盤掃描一樣，隻是在查詢時按照索引的順序進行掃碼而不是行。這樣會發生磁盤随機IO操作。
- 場景的有between 和 where中有 >、<這列的比較運算符。
- 有限制的索引範圍掃描。
- 叫ref是因為該索引要跟某個參考值進行對比。這個值可以是常量，也可以是多表查詢結果。
- 此類索引隻能是非唯一索引或者唯一索引中的非唯一字首。
- 索引範圍查找。
- 出現在主鍵或者唯一索引的情況中。
- 最多傳回一條符合條件的記錄。
- 例如 select * from table where id = 1;
- 能對查詢的某一個部分轉化為一個常量。
- 優化階段分解查詢語句，執行階段無需在查找表。
- 場景問題
- 說明：面試官一般會變着不同的方式問你，其實文問的無非就是同樣的基礎知識
- 主要就是羅列幾種索引失效的場景。可以根據上面的總結回顧。一般有wherein， like，聯合索引會多一點。
- 如果不是索引覆寫的情況下，就會進行回表查找。
- 是否所有的非聚集索引，都會重新回表查找一次？
- 列舉幾個索引字段，問你是否使用到索引？為什麼沒有用到？如何優化？
- 都有哪些索引？
- 索引的底層資料結構是怎麼樣的？
高可用
主從複制
- 簡述
- 容災備份
- 緩解高并發
- 是什麼：将一台服務的資料複制到其他的一台或者多台服務上。
- 為什麼
- 常見架構模式
- 一主一從
- 一主多從
- 級聯主從
- 多主一從
- 雙向主從
- 實作原理
- 重點參數
- 具體配置
- 同步模式
- 半同步複制
- 異步複制
- 實作模式
- GTID模式
- binary + Postion模式
- 常見問題
- 資料延遲
- 資料一緻性
資料備份與恢複
備份原因
- 災難恢複
- 測試使用
- 資料審計
備份方式
- 冷備份(停機備份)
- 熱備份方式一樣都可以
- 資料庫服務需要停止
- 資料完整性高
- 優點
- 缺點
- 備份方式
- 熱備份(運作時備份)
- 增加了資料庫服務壓力
- 容易出現資料不一緻性
- 不影響資料庫服務運作
- 裸檔案備份
- 邏輯備份
- xtrabackup
- 隻能導出資料，不能導出資料表
- 資料恢複快
- 多線程導出
- 單線程模式
- 會增加表鎖
- 導出的SQL語句，恢複慢
- 可讀性高
- mysqldump
- mysqldumper
- select xxx into outfile
- 備份方式
- 優點
- 缺點
備份結果
- 全量備份
- 增量備份