基于MySQL的存儲引擎與日志說明(全面講解)

2024-07-24 13:15:15

字體：大中小

來源：轉載

供稿：網友

1.1 存儲引擎的介紹

MySQL,存儲引擎,日志說明

1.1.1 文件系統存儲

文件系統：操作系統組織和存取數據的一種機制。文件系統是一種軟件。

類型：ext2 3 4 ，xfs 數據。不管使用什么文件系統，數據內容不會變化，不同的是，存儲空間、大小、速度。

1.1.2 mysql數據庫存儲

MySQL引擎：可以理解為，MySQL的“文件系統”，只不過功能更加強大。

MySQL引擎功能：除了可以提供基本的存取功能，還有更多功能事務功能、鎖定、備份和恢復、優化以及特殊功能。

1.1.3 MySQL存儲引擎種類

MySQL 提供以下存儲引擎：

InnoDB、MyISAM (最常用的兩種)MEMORY、ARCHIVE、FEDERATED、EXAMPLEBLACKHOLE、MERGE、NDBCLUSTER、CSV

除此之外還可以使用第三方存儲引擎。

1.1.4 innodb與myisam對比

InnoDb引擎

支持ACID的事務，支持事務的四種隔離級別；

支持行級鎖及外鍵約束：因此可以支持寫并發；

不存儲總行數；

一個InnoDb引擎存儲在一個文件空間（共享表空間，表大小不受操作系統控制，一個表可能分布在多個文件里），也有可能為多個（設置為獨立表空，表大小受操作系統文件大小限制，一般為2G），受操作系統文件大小的限制；

主鍵索引采用聚集索引（索引的數據域存儲數據文件本身），輔索引的數據域存儲主鍵的值；因此從輔索引查找數據，需要先通過輔索引找到主鍵值，再訪問輔索引；最好使用自增主鍵，防止插入數據時，為維持B+樹結構，文件的大調整。

Innodb的主索引結構如下：

MySQL,存儲引擎,日志說明

MyISAM引擎

不支持事務，但是每次查詢都是原子的；

支持表級鎖，即每次操作是對整個表加鎖；

存儲表的總行數；

一個MYISAM表有三個文件：索引文件、表結構文件、數據文件；

采用菲聚集索引，索引文件的數據域存儲指向數據文件的指針。輔索引與主索引基本一致，但是輔索引不用保證唯一性。

MYISAM的主索引結構如下：

MySQL,存儲引擎,日志說明

兩種索引數據查找過程如下：

MySQL,存儲引擎,日志說明

1.2 innodb存儲引擎

在MySQL5.5版本之后，默認的存儲引擎，提供高可靠性和高性能。

1.2.1 Innodb引擎的優點

a) 事務安全（遵從ACID）b) MVCC（Multi-Versioning Concurrency Control，多版本并發控制）c) InnoDB行級鎖d) 支持外鍵引用完整性約束e) 出現故障后快速自動恢復（crash safe recovery）f) 用于在內存中緩存數據和索引的緩沖區池（buffer pool（data buffer page log buffer page） 、undo buffer page）g) 大型數據卷上的最大性能h) 將對表的查詢與不同存儲引擎混合i) Oracle樣式一致非鎖定讀取(共享鎖)j) 表數據進行整理來優化基于主鍵的查詢（聚集索引）

1.2.2 Innodb功能總覽

功能	支持	功能	支持
存儲限制	64 TB	索引高速緩存	是
MVCC	是	數據高速緩存	是
B 樹索引	是	自適應散列索引	是
群集索引	是	復制	是
壓縮數據	是	更新數據字典	是
加密數據[b]	是	地理空間數據類型	是
查詢高速緩存	是	地理空間索引	否
事務	是	全文搜索索引	是
鎖定粒度	行	群集數據庫	否
外鍵	是	備份和恢復	是
文件格式管理	是	快速索引創建	是
多個緩沖區池	是	PERFORMANCE_SCHEMA	是
更改緩沖	是	自動故障恢復	是

1.2.3 查詢存儲引擎的方法

1、使用 SELECT 確認會話存儲引擎：

SELECT @@default_storage_engine;或show variables like '%engine%';

2、使用 SHOW 確認每個表的存儲引擎：

SHOW CREATE TABLE City/GSHOW TABLE STATUS LIKE 'CountryLanguage'/G

3、使用 INFORMATION_SCHEMA 確認每個表的存儲引擎：

SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLESWHERE TABLE_NAME = 'City'AND TABLE_SCHEMA = 'world_innodb'/G

4、從5.1版本，遷移到5.5版本以上版本

假如5.1版本數據庫所有生產表都是myisam的。

使用mysqldump備份后，一點要替換備份的文件中的engine(引擎)字段，從myisam替換為innodb（可以使用sed命令），否則遷移無任何意義。

數據庫升級時，要注意其他配套設施的兼容性，注意代碼能否兼容新特性。

1.2.4 設置存儲引擎

1、在啟動配置文件中設置服務器存儲引擎：

[mysqld]default-storage-engine=<Storage Engine>

2、使用 SET 命令為當前客戶機會話設置：

SET @@storage_engine=<Storage Engine>;

3、在 CREATE TABLE 語句指定：

CREATE TABLE t (i INT) ENGINE = <Storage Engine>;

1.3 InnoDB存儲引擎的存儲結構

1.3.1 InnoDB 系統表空間特性

默認情況下，InnoDB 元數據、撤消日志和緩沖區存儲在系統“表空間”中。

這是單個邏輯存儲區域，可以包含一個或多個文件。

每個文件可以是常規文件或原始分區。

最后的文件可以自動擴展。

1.3.2 表空間的定義

表空間：MySQL數據庫存儲的方式

表空間中包含數據文件

MySQl表空間和數據文件是1:1的關系

共享表空間除外，是可以1:N關系

MySQL,存儲引擎,日志說明

1.3.3 表空間類型

1、共享表空間：ibdata1~ibdataN,一般是2-3個

2、獨立表空間：存放在指定庫目錄下，例如data/world/目錄下的city.ibd

　　表空間位置（datadir）：

　　data/目錄下

1.3.4 系統表空間的存儲內容

共享表空間（物理存儲結構）

ibdata1~N 通常被叫做系統表空間，是數據初始化生成的

系統元數據，基表數據，除了表內容數據之外的數據。

tmp 表空間（一般很少關注）

undo日志：數據--回滾數據（回滾日志使用）

redo日志：ib_logfile0~N 存放系統的innodb表的一些重做日志。

說明：undo日志默認實在ibdata中的，在5.6以后是可以單獨定義的。

tmp 表空間在5.7版本之后被移出了ibdata1，變為ibtmp1

在5.5版本之前，所有的應用數據也都默認存放到了ibdata中。

獨立表空間(一個存儲引擎的功能)

在5.6之后，默認的情況下會單表單獨存儲到獨立表空間文件

除了系統表空間之外，InnoDB 還在數據庫目錄中創建另外的表空間，用于每個 InnoDB 表的 .ibd 文件。

InnoDB 創建的每個新表在數據庫目錄中設置一個 .ibd 文件來搭配表的.frm 文件。

可以使用 innodb_file_per_table 選項控制此設置，更改該設置僅會更改已創建的新表的默認值。。

MySQL,存儲引擎,日志說明

1.3.5 設置共享表空間

查看當前的共享表空間設置

mysql> show variables like 'innodb_data_file_path';+-----------------------+------------------------+| Variable_name | Value  |+-----------------------+------------------------+| innodb_data_file_path | ibdata1:12M:autoextend |+-----------------------+------------------------+row in set (0.00 sec)

設置共享表空間：

一般是在初始搭建環境的時候就配置號，預設值一般為1G；且最后一個為自動擴展。

[root@db02 world]# vim /etc/my.cnf[mysqld]innodb_data_file_path=ibdata1:76M;ibdata2:100M:autoextend

重啟服務查看當前的共享表空間設置

mysql> show variables like 'innodb_data_file_path';+-----------------------+-------------------------------------+| Variable_name | Value  |+-----------------------+-------------------------------------+| innodb_data_file_path | ibdata1:76M;ibdata2:100M:autoextend |+-----------------------+-------------------------------------+row in set (0.00 sec)

1.3.6 設置獨立表空間

獨立表空間在5.6版本是默認開啟的。

獨立表空間注意事項：不開起獨立表空間，共享表空間會占用很大

mysql> show variables like '%per_table%';+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| innodb_file_per_table | ON |+-----------------------+-------+row in set (0.00 sec)

在參數文件/etc/my.cnf 可以控制獨立表空間

關閉獨立表空間（0是關閉，1是開啟）

[root@db02 clsn]# vim /etc/my.cnf[mysqld]innodb_file_per_table=0

查看獨立表空間配置

mysql> show variables like '%per_table%' ;+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| innodb_file_per_table | OFF |+-----------------------+-------+row in set (0.00 sec)

小結:

innodb_file_per_table=0 關閉獨立表空間innodb_file_per_table=1 開啟獨立表空間，單表單存儲

1.4 MySQL中的事務

一組數據操作執行步驟，這些步驟被視為一個工作單元

用于對多個語句進行分組，可以在多個客戶機并發訪問同一個表中的數據時使用。

所有步驟都成功或都失敗

如果所有步驟正常，則執行，如果步驟出現錯誤或不完整，則取消。

簡單來說事務就是：保證工作單元中的語句同時成功或同時失敗。

MySQL,存儲引擎,日志說明

事務處理流程示意圖

1.4.1 事務是什么

與其給事務定義，不如說一說事務的特性。眾所周知，事務需要滿足ACID四個特性。

A(atomicity) 原子性。

一個事務的執行被視為一個不可分割的最小單元。事務里面的操作，要么全部成功執行，要么全部失敗回滾，不可以只執行其中的一部分。

所有語句作為一個單元全部成功執行或全部取消。updata t1 set money=10000-17 where id=wxid1updata t1 set money=10000+17 where id=wxid2

C(consistency) 一致性。

一個事務的執行不應該破壞數據庫的完整性約束。如果上述例子中第2個操作執行后系統崩潰，保證A和B的金錢總計是不會變的。

如果數據庫在事務開始時處于一致狀態，則在執行該事務期間將保留一致狀態。 updata t1 set money=10000-17 where id=wxid1 updata t1 set money=10000+17 where id=wxid2 在以上操作過程中，去查自己賬戶還是10000

I(isolation) 隔離性。

通常來說，事務之間的行為不應該互相影響。然而實際情況中，事務相互影響的程度受到隔離級別的影響。文章后面會詳述。

事務之間不相互影響。在做操作的時候，其他人對這兩個賬戶做任何操作，在不同的隔離條件下，可能一致性保證又不一樣

隔離級別

隔離級別會影響到一致性。 read-uncommit X read-commit 可能會用的一種級別 repeatable-read 默認的級別，和oracle一樣的 SERIALIZABLE 嚴格的默認，一般不會用

此規則除了受隔離級別控制，還受鎖控制，可以聯想一下NFS的實現

D(durability) 持久性。

事務提交之后，需要將提交的事務持久化到磁盤。即使系統崩潰，提交的數據也不應該丟失。

保證數據落地，才算事務真正安全

1.4.2 事務的控制語句

常用的事務控制語句：

START TRANSACTION（或 BEGIN）：顯式開始一個新事務 COMMIT：永久記錄當前事務所做的更改(事務成功結束) ROLLBACK：取消當前事務所做的更改(事務失敗結束)

需要知道的事務控制語句：

 SAVEPOINT：分配事務過程中的一個位置，以供將來引用 ROLLBACK TO SAVEPOINT：取消在 savepoint 之后執行的更改 RELEASE SAVEPOINT：刪除 savepoint 標識符 SET AUTOCOMMIT：為當前連接禁用或啟用默認 autocommit模式

1.4.3 autocommit參數

在MySQL5.5開始，開啟事務時不再需要begin或者start transaction語句。并且，默認是開啟了Autocommit模式，作為一個事務隱式提交每個語句。

在有些業務繁忙企業場景下，這種配置可能會對性能產生很大影響，但對于安全性上有很大提高。將來，我們需要去權衡我們的業務需求去調整是否自動提交。

注意：在生產中，根據實際需求選擇是否可開啟，一般銀行類業務會選擇關閉。

查看當前autocommit狀態：

mysql> show variables like '%autoc%';+---------------+-------+| Variable_name | Value |+---------------+-------+| autocommit | ON |+---------------+-------+row in set (0.00 sec)

修改配置文件，并重啟

[root@db02 world]# vim /etc/my.cnf[mysqld]autocommit=0

再次查看autocommit狀態

mysql> show variables like '%autoc%';+---------------+-------+| Variable_name | Value |+---------------+-------+| autocommit | OFF |+---------------+-------+row in set (0.00 sec)mysql> select @@autocommit;+--------------+| @@autocommit |+--------------+| 0 |+--------------+row in set (0.00 sec)

說明： autocommit設置為開啟的對比

優點：數據安全性好，每次修改都會落地

缺點：不能進行銀行類的交易事務、產生大量小的IO

1.4.4 導致提交的非事務語句：

DDL語句： （ALTER、CREATE 和 DROP）DCL語句： （GRANT、REVOKE 和 SET PASSWORD）鎖定語句：（LOCK TABLES 和 UNLOCK TABLES）

導致隱式提交的語句示例：

TRUNCATE TABLELOAD DATA INFILESELECT FOR UPDATE

用于隱式提交的 SQL 語句：

START TRANSACTIONSET AUTOCOMMIT = 1

1.5 redo與undo

MySQL,存儲引擎,日志說明

1.5.1 事務日志undo

undo原理：

Undo Log的原理很簡單，為了滿足事務的原子性，在操作任何數據之前，首先將數據備份到一個地方（這個存儲數據備份的地方稱為Undo Log）。然后進行數據的修改。

如果出現了錯誤或者用戶執行了ROLLBACK語句，系統可以利用Undo Log中的備份將數據恢復到事務開始之前的狀態。

除了可以保證事務的原子性，Undo Log也可以用來輔助完成事務的持久化。

MySQL,存儲引擎,日志說明

undo是什么？

undo,顧名思義“回滾日志”，是事務日志的一種。

作用是什么？

在事務ACID過程中，實現的是“A“原子性的作用。

用Undo Log實現原子性和持久化的事務的簡化過程

假設有A、B兩個數據，值分別為1,2。 A.事務開始. B.記錄A=1到undo log. C.修改A=3. D.記錄B=2到undo log. E.修改B=4. F.將undo log寫到磁盤。 G.將數據寫到磁盤。 H.事務提交

這里有一個隱含的前提條件：‘數據都是先讀到內存中，然后修改內存中的數據，最后將數據寫回磁盤之所以能同時保證原子性和持久化，是因為以下特點：

A. 更新數據前記錄Undo log。B. 為了保證持久性，必須將數據在事務提交前寫到磁盤。只要事務成功提交，數據必然已經持久化。C. Undo log必須先于數據持久化到磁盤。如果在G,H之間系統崩潰，undo log是完整的，可以用來回滾事務。D. 如果在A-F之間系統崩潰,因為數據沒有持久化到磁盤。所以磁盤上的數據還是保持在事務開始前的狀態。

缺陷：

每個事務提交前將數據和Undo Log寫入磁盤，這樣會導致大量的磁盤IO，因此性能很低。如果能夠將數據緩存一段時間，就能減少IO提高性能。但是這樣就會喪失事務的持久性。

因此引入了另外一種機制來實現持久化，即Redo Log.

1.5.2 事務日志redo

redo原理：

和Undo Log相反，Redo Log記錄的是新數據的備份。在事務提交前，只要將Redo Log持久化即可，不需要將數據持久化。當系統崩潰時，雖然數據沒有持久化，但是Redo Log已經持久化。

系統可以根據Redo Log的內容，將所有數據恢復到最新的狀態。

MySQL,存儲引擎,日志說明

Redo是什么？

redo,顧名思義“重做日志”，是事務日志的一種。

作用是什么？

在事務ACID過程中，實現的是“D”持久化的作用。

Undo + Redo事務的簡化過程

假設有A、B兩個數據，值分別為1,2. A.事務開始. B.記錄A=1到undo log. C.修改A=3. D.記錄A=3到redo log. E.記錄B=2到undo log. F.修改B=4. G.記錄B=4到redo log. H.將redo log寫入磁盤。 I.事務提交

Undo + Redo事務的特點

 A. 為了保證持久性，必須在事務提交前將Redo Log持久化。 B. 數據不需要在事務提交前寫入磁盤，而是緩存在內存中。 C. Redo Log 保證事務的持久性。 D. Undo Log 保證事務的原子性。 E. 有一個隱含的特點，數據必須要晚于redo log寫入持久存儲。

redo是否持久化到磁盤參數

innodb_flush_log_at_trx_commit=1/0/2

1.5.3 事務中的鎖

什么是“鎖”？

“鎖”顧名思義就是鎖定的意思。

“鎖”的作用是什么？

在事務ACID過程中，“鎖”和“隔離級別”一起來實現“I”隔離性的作用。

MySQL,存儲引擎,日志說明

鎖的粒度：

1、MyIasm：低并發鎖——表級鎖

2、Innodb：高并發鎖——行級鎖

四種隔離級別：

READ UNCOMMITTED 許事務查看其他事務所進行的未提交更改READ COMMITTED 允許事務查看其他事務所進行的已提交更改REPEATABLE READ****** 確保每個事務的 SELECT 輸出一致； InnoDB 的默認級別SERIALIZABLE 將一個事務的結果與其他事務完全隔離

開銷、加鎖速度、死鎖、粒度、并發性能

表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高,并發度最低。行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低,并發度也最高。頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般。

從上述特點可見，很難籠統地說哪種鎖更好，只能就具體應用的特點來說哪種鎖更合適！

僅從鎖的角度來說：表級鎖更適合于以查詢為主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則更適合于有大量按索引條件并發更新少量不同數據，同時又有并發查詢的應用，如一些在線事務處理（OLTP）系統。

1.6 MySQL 日志管理

1.6.1 MySQL日志類型簡介

日志的類型的說明：

日志文件	選項	文件名	程序 N/A
		表名稱
錯誤	--log-error	host_name.err	N/A
常規	--general_log	host_name.log	mysqldumpslow mysqlbinlog
		general_log
慢速查詢	--slow_query_log --long_query_time	host_name-slow.log	N/A 程序
		slow_log
二進制	--log-bin --expire-logs-days	host_name-bin.000001	N/A
審計	--audit_log --audit_log_file	audit.log	N/A

1.6.2 配置方法

狀態錯誤日志：

[mysqld]log-error=/data/mysql/mysql.log

查看配置方式：

mysql> show variables like '%log%error%';

作用：

記錄mysql數據庫的一般狀態信息及報錯信息，是我們對于數

據庫常規報錯處理的常用日志。

mysql> show variables like '%log%err%';+---------------------+----------------------------------+| Variable_name | Value  |+---------------------+----------------------------------+| binlog_error_action | IGNORE_ERROR  || log_error | /application/mysql/data/db02.err |+---------------------+----------------------------------+rows in set (0.00 sec)

1.6.3 一般查詢日志

配置方法:

[mysqld]general_log=ongeneral_log_file=/data/mysql/server2.log

查看配置方式：

show variables like '%gen%';

作用：

記錄mysql所有執行成功的SQL語句信息，可以做審計用，但是我們很少開啟

mysql> show variables like '%gen%';+------------------+----------------------------------+| Variable_name | Value  |+------------------+----------------------------------+| general_log | OFF  || general_log_file | /application/mysql/data/db02.log |+------------------+----------------------------------+rows in set (0.00 sec)

1.7 二進制日志

二進制日志不依賴與存儲引擎的。

依賴于sql層，記錄和sql語句相關的信息

binlog日志作用：

1、提供備份功能

2、進行主從復制

3、基于時間點的任意恢復

記錄在sql層已經執行完成的語句，如果是事務，則記錄已完成的事務。

功能作用：時間點備份和時間點恢復、主從

二進制日志的“總閘”

作用：

1、是否開啟2、二進制日志路徑/data/mysql/3、二進制日志文件名前綴mysql-bin 4、文件名以"前綴".000001~Nlog-bin=/data/mysql/mysql-bin

二進制日志的“分開關”：

只有總閘開啟才有意義，默認是開啟狀態。我們在有些時候會臨時關閉掉。只影響當前會話。sql_log_bin=1/0

1.7.1 二進制日志的格式

statement，語句模式：

記錄信息簡潔，記錄的是SQL語句本身。但是在語句中出現函數操作的話，有可能記錄的數據不準確。5.6中默認模式，但生產環境中慎用，建議改成row。

row，行模式

表中行數據的變化過程。記錄數據詳細，對IO性能要求比較高記錄數據在任何情況下都是準確的。生產中一般是這種模式。5.7以后默認的模式。

mixed，混合模式

經過判斷，選擇row+statement混合的一種記錄模式。（一般不用）

1.7.2 開啟二進制日志

mysql> show variables like '%log_bin%';+---------------------------------+-------+| Variable_name  | Value |+---------------------------------+-------+| log_bin  | OFF || log_bin_basename | || log_bin_index  | || log_bin_trust_function_creators | OFF || log_bin_use_v1_row_events | OFF || sql_log_bin  | ON |+---------------------------------+-------+rows in set (0.00 sec)

修改配置文件開啟二進制日志

[root@db02 tmp]# vim /etc/my.cnf[mysqld]log-bin=/application/mysql/data/mysql-bin

命令行修改的方法

mysql> SET GLOBAL binlog_format = 'STATEMENT'mysql> SET GLOBAL binlog_format = 'ROW';mysql> SET GLOBAL binlog_format = 'MIXED';

查看文件二進制日志的類型

[root@db02 data]# file mysql-bin.*mysql-bin.000001: MySQL replication logmysql-bin.index: ASCII text

查看MySQL的配置：

mysql> show variables like '%log_bin%';+---------------------------------+-----------------------------------------+| Variable_name  | Value   |+---------------------------------+-----------------------------------------+| log_bin  | ON   || log_bin_basename | /application/mysql/data/mysql-bin || log_bin_index  | /application/mysql/data/mysql-bin.index || log_bin_trust_function_creators | OFF   || log_bin_use_v1_row_events | OFF   || sql_log_bin  | ON   |+---------------------------------+-----------------------------------------+rows in set (0.00 sec)

1.7.3 定義記錄方式

查看現在的格式

mysql> show variables like '%format%';+--------------------------+-------------------+| Variable_name | Value |+--------------------------+-------------------+| binlog_format | STATEMENT || date_format | %Y-%m-%d || datetime_format | %Y-%m-%d %H:%i:%s || default_week_format | 0  || innodb_file_format | Antelope || innodb_file_format_check | ON || innodb_file_format_max | Antelope || time_format | %H:%i:%s |+--------------------------+-------------------+rows in set (0.00 sec)

修改格式

[root@db02 data]# vim /etc/my.cnf[mysqld]binlog_format=row

改完之后查看

mysql> show variables like '%format%';+--------------------------+-------------------+| Variable_name | Value |+--------------------------+-------------------+| binlog_format | ROW || date_format | %Y-%m-%d || datetime_format | %Y-%m-%d %H:%i:%s || default_week_format | 0  || innodb_file_format | Antelope || innodb_file_format_check | ON || innodb_file_format_max | Antelope || time_format | %H:%i:%s |+--------------------------+-------------------+rows in set (0.00 sec)

1.8 二進制日志的操作

1.8.1 查看

操作系統層面查看

[root@db02 data]# ll mysql-bin.*-rw-rw---- 1 mysql mysql 143 Dec 20 20:17 mysql-bin.000001-rw-rw---- 1 mysql mysql 120 Dec 20 20:17 mysql-bin.000002-rw-rw---- 1 mysql mysql 82 Dec 20 20:17 mysql-bin.index

刷新日志

mysql> flush logs;

刷新完成后的日志目錄

[root@db02 data]# ll mysql-bin.*-rw-rw---- 1 mysql mysql 143 Dec 20 20:17 mysql-bin.000001-rw-rw---- 1 mysql mysql 167 Dec 20 20:24 mysql-bin.000002-rw-rw---- 1 mysql mysql 120 Dec 20 20:24 mysql-bin.000003-rw-rw---- 1 mysql mysql 123 Dec 20 20:24 mysql-bin.index[root@db02 data]#

查看當前使用的二進制日志文件

mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000003 | 120 | |  |  |+------------------+----------+--------------+------------------+-------------------+row in set (0.00 sec)

查看所有的二進制日志文件

mysql> show binary logs;+------------------+-----------+| Log_name | File_size |+------------------+-----------+| mysql-bin.000001 | 143 || mysql-bin.000002 | 167 || mysql-bin.000003 | 120 |+------------------+-----------+rows in set (0.00 sec)

1.8.2 查看二進制日志內容

名詞說明：

1、events 事件

二進制日志如何定義：命令的最小發生單元

2、position

每個事件在整個二進制文件中想對應的位置號就是position號

mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000003 | 120 | |  |  |+------------------+----------+--------------+------------------+-------------------+row in set (0.00 sec)[root@db02 data]# mysqlbinlog mysql-bin.000003 >/tmp/aa.ttt

導出所有的信息

[root@db02 data]# mysqlbinlog mysql-bin.000003 >/tmp/aa.ttt

binlog的查看方式：

1、查看binlog原始信息

mysqbin mysql-bin.000002

2、在row模式下，翻譯成語句

mysqlbinlog --base64-output='decode-rows' -v mysql-bin.000002

3、查看binlog事件

show binary logs; 所有在使用的binlog信息show binlog events in '日志文件'

4、如何截取binlog內容，按需求恢復（常規思路）

（1）、show binary logs; show master status;

（2）、show binlog events in '' 從后往前看，找到誤操作的事務，判斷事務開始position和結束position

（3）、把誤操作的剔除掉，留下正常操作到2個sql文件中

（4）、先測試庫恢復，把誤操作的數據導出，然后生產恢復。

使用上述方法遇到的問題：

恢復事件較長

對生產數據有一定的影響，有可能會出現冗余數據

較好的解決方案。

1、flashback閃回功能

2、通過備份，延時從庫

1.8.3 mysqlbinlog截取二進制日志的方法

mysqlbinlog常見的選項有以下幾個：

參數	參數說明
--start-datetime	從二進制日志中讀取指定等于時間戳或者晚于本地計算機的時間
--stop-datetime	從二進制日志中讀取指定小于時間戳或者等于本地計算機的時間取值和上述一樣
--start-position	從二進制日志中讀取指定position 事件位置作為開始。
--stop-position	從二進制日志中讀取指定position 事件位置作為事件截至