国产无码综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

<span id="odo1k"><meter id="odo1k"></meter></span><rt id="odo1k"></rt>

《MySQL高級篇》十五、其他數(shù)據(jù)庫日志

2年前作者：愛編程的大李子分類：Toy博客閱讀(84)違法舉報(bào)

這篇具有很好參考價(jià)值的文章主要介紹了《MySQL高級篇》十五、其他數(shù)據(jù)庫日志。希望對大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方，請大家不吝賜教，您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問。

我們在講解數(shù)據(jù)庫事務(wù)時(shí)，講過兩種日志:重做日志、回滾日志。

對于線上數(shù)據(jù)庫應(yīng)用系統(tǒng)，突然遭遇數(shù)據(jù)庫宕機(jī)怎么辦?在這種情況下，定位宕機(jī)的原因就非常關(guān)鍵。可以查看數(shù)據(jù)庫的錯(cuò)誤日志。因?yàn)槿罩局杏涗浟藬?shù)據(jù)庫運(yùn)行中的診斷信息，包括了錯(cuò)誤、警告和注釋等信息。比如:從日志中發(fā)現(xiàn)某個(gè)連接中的SQL操作發(fā)生了死循環(huán)，導(dǎo)致內(nèi)存不足，被系統(tǒng)強(qiáng)行終止了。明確了原因，處理起來也就輕松了，系統(tǒng)很快就恢復(fù)了運(yùn)行。

除了發(fā)現(xiàn)錯(cuò)誤，日志在數(shù)據(jù)復(fù)制、數(shù)據(jù)恢復(fù)、操作審計(jì)，以及確保數(shù)據(jù)的永久性和一致性等方面，都有著不可替代的作用。

千萬不要小看日志。很多看似奇怪的問題，答案往往就藏在日志里。很多情況下，只有通過查看日志才能發(fā)現(xiàn)問題的原因，真正解決問題。所以，一定要學(xué)會(huì)查看日志，養(yǎng)成檢查日志的習(xí)慣，對提升你的數(shù)據(jù)庫應(yīng)用開發(fā)能力至關(guān)重要。

MySQL8.0官網(wǎng)日志地址: https://dev.mysql.com/doc/refman/8.0/en/server-logs.html

1. MySQL支持的日志

1.1 日志類型

MySQL有不同類型的日志文件，用來存儲(chǔ)不同類型的日志，分為二進(jìn)制日志、錯(cuò)誤日志、通用查詢?nèi)罩?/code>和慢查詢?nèi)罩?/code>，這也是常用的4種。MySQL 8又新增兩種支持的日志:中繼日志和數(shù)據(jù)定義語句日志。使用這些日志文件，可以查看MySQL內(nèi)部發(fā)生的事情。

 
這6類日志分別為： 


慢查詢?nèi)罩?/code>:記錄所有執(zhí)行時(shí)間超過long_query_time的所有查詢，方便對查詢進(jìn)行優(yōu)化。


通用查詢?nèi)罩?/code>:記錄所有連接的起始時(shí)間和終止時(shí)間，以及連接發(fā)送給數(shù)據(jù)庫服務(wù)器的所有指令，對復(fù)原操作的實(shí)際場景、發(fā)現(xiàn)問題，甚至是對數(shù)據(jù)庫操作的審計(jì)都有很大的幫助。


錯(cuò)誤日志:記錄MySQL服務(wù)的啟動(dòng)、運(yùn)行或停止MySQL服務(wù)時(shí)出現(xiàn)的問題，方便我們了解服務(wù)器的狀態(tài)，從而從而對服務(wù)器進(jìn)行維護(hù)。

二進(jìn)制日志:記錄所有更改數(shù)據(jù)的語句，可以用于主從服務(wù)器之間的數(shù)據(jù)同步，以及服務(wù)器遇到故障時(shí)數(shù)據(jù)的無損失恢復(fù)。

中繼日志:用于主從服務(wù)器架構(gòu)中，從服務(wù)器用來存放主服務(wù)器二進(jìn)制日志內(nèi)容的一個(gè)中間文件。從服務(wù)器通過讀取中繼日志的內(nèi)容，來同步主服務(wù)器上的操作。

數(shù)據(jù)定義語句日志:記錄數(shù)據(jù)定義語句執(zhí)行的元數(shù)據(jù)操作。

除二進(jìn)制日志外，其他日志都是文本文件。默認(rèn)情況下，所有日志創(chuàng)建于MySQL數(shù)據(jù)目錄中。 
1.2 日志的弊端 

日志功能會(huì)降低MySQL數(shù)據(jù)庫的性能。例如，在查詢非常頻繁的MySQL數(shù)據(jù)庫系統(tǒng)中，如果開啟了通用查詢?nèi)罩竞吐樵內(nèi)罩?，MySQL數(shù)據(jù)庫會(huì)花費(fèi)很多時(shí)間記錄日志。
日志會(huì)占用大量的磁盤空間。對于用戶量非常大、操作非常頻繁的數(shù)據(jù)庫，日志文件需要的存儲(chǔ)空間設(shè)置比數(shù)據(jù)庫文件需要的存儲(chǔ)空間還要大。


2. 慢查詢?nèi)罩?slow query log) 
前面章節(jié)《第07章 性能分析工具的使用》已經(jīng)詳細(xì)講述 
3. 通用查詢?nèi)罩?/h3> 
通用查詢?nèi)罩居脕?code>記錄用戶的所有操作，包括啟動(dòng)和關(guān)閉MysQL服務(wù)、所有用戶的連接開始時(shí)間和截止時(shí)間、發(fā)給MySQL數(shù)據(jù)庫服務(wù)器的所有SQL指令等。當(dāng)我們的數(shù)據(jù)發(fā)生異常時(shí)**，查看通用查詢?nèi)罩?，還原操作時(shí)的具體場景** ，可以幫助我們準(zhǔn)確定位問題。 
3.1 問題場景 
在電商系統(tǒng)中，購買商品并且使用微信支付完成以后，卻發(fā)現(xiàn)支付中心的記錄并沒有新增，此時(shí)用戶再次使用支付寶支付，就會(huì)出現(xiàn)重復(fù)支付的問題。但是當(dāng)去數(shù)據(jù)庫中查詢數(shù)據(jù)的時(shí)候，會(huì)發(fā)現(xiàn)只有一條記錄存在。那么此時(shí)給到的現(xiàn)象就是只有一條支付記錄，但是用戶卻支付了兩次。 
對系統(tǒng)進(jìn)行了仔細(xì)檢查，沒有發(fā)現(xiàn)數(shù)據(jù)問題，因?yàn)橛脩艟幪柡陀唵尉幪栆约暗谌搅魉柖际菍Φ?。可是用戶確實(shí)支付了兩次，這個(gè)時(shí)候，我們想到了檢查通用查詢?nèi)罩?，看看?dāng)天到底發(fā)生了什么。 
查看之后，發(fā)現(xiàn): 1月1日下午2點(diǎn)，用戶使用微信支付完以后，但是由于網(wǎng)絡(luò)故障，支付中心沒有及時(shí)收到微信支付的回調(diào)通知，導(dǎo)致當(dāng)時(shí)沒有寫入數(shù)據(jù)。1月1日下午2點(diǎn)30，用戶又使用支付寶支付，此時(shí)記錄更新到支付中心。1月1日晚上9點(diǎn)，微信的回調(diào)通知過來了，但是支付中心已經(jīng)存在了支付寶的記錄，所以只能覆蓋記錄了。 
由于網(wǎng)絡(luò)的原因?qū)е铝酥貜?fù)支付。至于解決問題的方案就很多了，這里省略。 
可以看到通用查詢?nèi)罩究梢詭椭覀兞私獠僮靼l(fā)生的具體時(shí)間和操作的細(xì)節(jié)，對找出異常發(fā)生的原因極其關(guān)鍵。 
3.2 查看當(dāng)前狀態(tài) 
mysql> SHOW VARIABLES LIKE '%general%';
+------------------+------------------------------+
| Variable_name    | Value                        |
+------------------+------------------------------+
| general_log      | OFF                          |
| general_log_file | /var/lib/mysql/hadoop102.log |
+------------------+------------------------------+
2 rows in set (0.00 sec)
 
說明1∶系統(tǒng)變量general_log的值是OFF，即通用查詢?nèi)罩咎幱陉P(guān)閉狀態(tài)。在MySQL中，這個(gè)參數(shù)的默認(rèn)值是關(guān)閉的。因?yàn)橐坏╅_啟記錄通用查詢?nèi)罩?，MySQL 會(huì)記錄所有的連接起止和相關(guān)的SQL操作，這樣會(huì)消耗系統(tǒng)資源并且占用磁盤空間。我們可以通過手動(dòng)修改變量的值，在要的時(shí)候開啟日志。 
說明2:通用查詢?nèi)罩疚募拿Q是主機(jī).log(hadoop102.log)。存儲(chǔ)路徑是/var/lib/mysql/，默認(rèn)也是數(shù)據(jù)路徑。這樣我們就知道在哪里可以查看通用查詢?nèi)罩镜膬?nèi)容了 
3.3 啟動(dòng)日志 
方式1：永久性方式 
修改my.cnf或者my.ini配置文件來設(shè)置。在[mysqld]組下加入log選項(xiàng)，并重啟MySQL服務(wù)。格式如下： 
[mysqld]
general_log=ON
general_log_file=[path[filename]] #日志文件所在目錄路徑，filename為日志文件名
 
如果不指定目錄和文件名，通用查詢?nèi)罩緦⒛J(rèn)存儲(chǔ)在MySQL數(shù)據(jù)目錄中的hostname.log文件中，hostname表示主機(jī)名。 
方式2：臨時(shí)性方式 
使用SET語句停止MySQL通用查詢?nèi)罩竟δ? 
SET GLOBAL general_log=on; # 開啟通用查詢?nèi)罩?/span>
SET GLOBAL general_log_file='path/filename'; # 設(shè)置日志文件保存位置
 
對應(yīng)的，關(guān)閉操作SQL命令如下： 
SET GLOBAL general_log=off; # 關(guān)閉通用查詢?nèi)罩?/span>
 
查看設(shè)置后情況： 
SHOW VARIABLES LIKE 'general_log%';
 
3.4 查看日志 
通用查詢?nèi)罩臼且?code>文本文件 的形式存儲(chǔ)在文件系統(tǒng)中的，可以使用文本編輯器 直接打開日志文件。每臺MySQL服務(wù)器的通用查詢?nèi)罩緝?nèi)容是不同的。 

在Windows操作系統(tǒng)中，使用文本文件查看器；
在Linux系統(tǒng)中，可以使用vi工具或者gedit工具查看；
在Mac OSX系統(tǒng)中，可以使用文本文件查看器或者vi等工具查看。

從SHOW VARIABLES LIKE ‘general_log%’; 結(jié)果中可以看到通用查詢?nèi)罩镜奈恢谩?/p> 
[root@hadoop102 mysql]# cat hadoop102.log 
/usr/sbin/mysqld, Version: 8.0.25 (MySQL Community Server - GPL). started with:
Tcp port: 3306  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
2023-07-09T11:06:37.920806Z	   12 Query	SHOW VARIABLES LIKE '%general%'
2023-07-10T00:49:48.408063Z	   12 Quit	
/usr/sbin/mysqld, Version: 8.0.25 (MySQL Community Server - GPL). started with:
Tcp port: 3306  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
2023-07-22T06:29:01.004735Z	   11 Query	SELECT DATABASE()
2023-07-22T06:29:01.004903Z	   11 Init DB	atguigudb2
2023-07-22T06:29:01.005518Z	   11 Query	show databases
2023-07-22T06:29:01.006686Z	   11 Query	show tables
2023-07-22T06:29:01.007981Z	   11 Field List	a 
2023-07-22T06:29:01.008874Z	   11 Field List	b 
2023-07-22T06:29:01.009481Z	   11 Field List	book 
2023-07-22T06:29:01.010170Z	   11 Field List	class 
2023-07-22T06:29:01.011040Z	   11 Field List	student 
2023-07-22T06:29:01.011209Z	   11 Field List	type 
2023-07-22T06:29:01.011303Z	   11 Field List	user3 
2023-07-22T06:29:13.504517Z	   11 Query	select * from student
2023-07-22T06:29:32.236803Z	   11 Query	select * from type
2023-07-22T06:29:58.236644Z	   11 Quit	
 
在通用查詢?nèi)罩纠锩妫覀兛梢郧宄乜吹?，什么時(shí)候開啟了新的客戶端登陸數(shù)據(jù)庫，登錄之后做了什么 SQL 操作，針對的是哪個(gè)數(shù)據(jù)表等信息。 
3.5 停止日志 
方式1：永久性方式
 修改 my.cnf 或者 my.ini 文件，把[mysqld]組下的 general_log 值設(shè)置為 OFF 或者把general_log一項(xiàng)注釋掉。修改保存后，再 重啟MySQL服務(wù) ，即可生效。 
舉例1： 
[mysqld]
general_log=OFF
 
舉例2： 
[mysqld]
#general_log=ON
 
方式2：臨時(shí)性方式
 使用SET語句停止MySQL通用查詢?nèi)罩竟δ埽?/p> 
SET GLOBAL general_log=off;
 
查詢通用日志功能： 
SHOW VARIABLES LIKE 'general_log%';
 
3.6 刪除\刷新日志 
如果數(shù)據(jù)的使用非常頻繁，那么通用查詢?nèi)罩緯?huì)占用服務(wù)器非常大的磁盤空間。數(shù)據(jù)管理員可以刪除很長時(shí)間之前的查詢?nèi)罩?，以保證MySQL服務(wù)器上的硬盤空間 
手動(dòng)刪除文件 
SHOW VARIABLES LIKE 'general_log%';
 
可以看出，通用查詢?nèi)罩镜哪夸浤J(rèn)為MySQL數(shù)據(jù)目錄。在該目錄下手動(dòng)刪除通用查詢?nèi)罩緃adoop01.log。 
使用如下命令重新生成查詢?nèi)罩疚募?，具體命令如下。刷新MySQL數(shù)據(jù)目錄，發(fā)現(xiàn)創(chuàng)建了新的日志文件。前提一定要開啟通用日志。 
mysqladmin -uroot -p flush-logs
 
如果希望備份舊的通用查詢?nèi)罩?，就必須先將舊的日志文件復(fù)制出來或者改名，然后執(zhí)行上面的mysqladmin命令。正確流程如下 
cd mysql-data-directory #輸入自己的通用日志文件所在目錄
mv mysql.general.log mysql.general.log.old #指名就的文件名 以及新的文件名
mysqladmin -uroot -p flush-logs
 
4. 錯(cuò)誤日志(error log) 
錯(cuò)誤日志記錄了MySQL服務(wù)器啟動(dòng)、停止運(yùn)行的時(shí)間，以及系統(tǒng)啟動(dòng)、運(yùn)行和停止過程中的診斷信息，包括錯(cuò)誤、警告和提示等。 
通過錯(cuò)誤日志可以查看系統(tǒng)的運(yùn)行狀態(tài)，便于即時(shí)發(fā)現(xiàn)故障、修復(fù)故障。如果MysQL服務(wù)出現(xiàn)異常，錯(cuò)誤日志是發(fā)現(xiàn)問題、解決故障的首選。 
4.1 啟動(dòng)日志 
在MySQL數(shù)據(jù)庫中，錯(cuò)誤日志功能是 默認(rèn)開啟 的。而且，錯(cuò)誤日志 無法被禁止 。 
默認(rèn)情況下，錯(cuò)誤日志存儲(chǔ)在MySQL數(shù)據(jù)庫的數(shù)據(jù)文件夾下，名稱默認(rèn)為 mysqld.log （Linux系統(tǒng)）或 hostname.err （mac系統(tǒng)）。如果需要制定文件名，則需要在my.cnf或者my.ini中做如下配置： 
[mysqld]
log-error=[path/[filename]] #path為日志文件所在的目錄路徑，filename為日志文件名
 
修改配置項(xiàng)后，需要重啟MySQL服務(wù)以生效。 
4.2 查看日志 
MySQL錯(cuò)誤日志是以文本文件形式存儲(chǔ)的，可以使用文本編輯器直接查看。 
查詢錯(cuò)誤日志的存儲(chǔ)路徑： 
mysql> SHOW VARIABLES LIKE 'log_err%';
+----------------------------+----------------------------------------+
| Variable_name              | Value                                  |
+----------------------------+----------------------------------------+
| log_error                  | /var/log/mysqld.log                    |
| log_error_services         | log_filter_internal; log_sink_internal |
| log_error_suppression_list |                                        |
| log_error_verbosity        | 2                                      |
+----------------------------+----------------------------------------+
4 rows in set (0.00 sec)
 
執(zhí)行結(jié)果中可以看到錯(cuò)誤日志文件是mysqld.log，位于MySQL默認(rèn)的數(shù)據(jù)目錄下。 
下面我們查看一下錯(cuò)誤日志的內(nèi)容。 
[root@hadoop102 log]# cat mysqld.log
2022-05-09T13:36:18.316947Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.25) initializing of server in progress as process 8770
2022-05-09T13:36:18.339461Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-05-09T13:36:18.969919Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2022-05-09T13:36:20.519755Z 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: wtOQr<yC9NHM
2022-05-09T13:37:00.981062Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.25) starting as process 8872
2022-05-09T13:37:00.993416Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-05-09T13:37:01.118904Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2022-05-09T13:37:01.211523Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
//...
 
可以看到，錯(cuò)誤日志文件中記錄了服務(wù)器啟動(dòng)的時(shí)間，以及存儲(chǔ)引擎InnoDB啟動(dòng)和停止等，我們在做初始化時(shí)候生成的數(shù)據(jù)庫初始密碼也是記錄在error.log中。 
4.3 刪除\刷新日志 
對于很久以前的錯(cuò)誤日志，數(shù)據(jù)庫管理員查看這些錯(cuò)誤日志的可能性不大，可以將這些錯(cuò)誤日志刪除，以保證MySQL服務(wù)器上的 硬盤空間 。MySQL的錯(cuò)誤日志是以文本文件的形式存儲(chǔ)在文件系統(tǒng)中的，可以直接刪除。 

第1步(方式1)︰刪除操作 rm （ 在運(yùn)行狀態(tài)下刪除錯(cuò)誤日志文件后，MySQL并不會(huì)自動(dòng)創(chuàng)建日志文件）
第1步(方式2)︰重命名文件 mv

第2步：重建日志 mysqladmin -uroot -p flush-logs


可能報(bào)錯(cuò) 
[root@atguigu01 log]# mysqladmin -uroot -p flush-logs
Enter password:
mysqladmin: refresh failed; error: 'Could not open file '/var/log/mysqld.log' for error logging.'
 
官網(wǎng)提示: 
 
執(zhí)行下面命令： 
install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log
 
flush-logs指令操作: 
MySQL 5.5.7以前的版本，flush-logs將錯(cuò)誤日志文件重命名為filename.err_old，并創(chuàng)建新的日志文件。
 從MySQL 5.5.7開始，flush-logs只是重新打開日志文件，并不做日志備份和創(chuàng)建的操作。
 如果日志文件不存在，MySQL啟動(dòng)或者執(zhí)行flush-logs時(shí)會(huì)自動(dòng)創(chuàng)建新的日志文件。重新創(chuàng)建錯(cuò)誤日志，大小為0字節(jié)。 
4.4 MySQL8.0新特性 
MySQL8.0里對錯(cuò)誤日志的改進(jìn)。MySQL8.0的錯(cuò)誤日志可以理解為一個(gè)全新的日志，在這個(gè)版本里，接受了來自社區(qū)的廣泛批評意見，在這些意見和建議的基礎(chǔ)上生成了新的日志。 

下面這些是來自社區(qū)的意見:
默認(rèn)情況下內(nèi)容過于冗長
遺漏了有用的信息
難以過濾某些信息
沒有標(biāo)識錯(cuò)誤信息的子系統(tǒng)源
沒有錯(cuò)誤代碼，解析消息需要識別錯(cuò)誤
引導(dǎo)消息可能會(huì)丟失
固定格式

針對這些意見，MySQL做了如下改變: 

采用組件架構(gòu)，通過不同的組件執(zhí)行日志的寫入和過濾功能
寫入錯(cuò)誤日志的全部信息都具有唯一的錯(cuò)誤代碼從10000開始
增加了一個(gè)新的消息分類《system》用于在錯(cuò)誤日志中始終可見的非錯(cuò)誤但服務(wù)器狀態(tài)更改事件的消息。增加了額外的附加信息，例如關(guān)機(jī)時(shí)的版本信息，誰發(fā)起的關(guān)機(jī)等等
兩種過濾方式，Internal和Dragnet
三種寫入形式，經(jīng)典、JSON和syseventlog

 
 小結(jié): 
 通常情況下，管理員不需要查看錯(cuò)誤日志。但是，MySQL服務(wù)器發(fā)生異常時(shí)，管理員可以從錯(cuò)誤日志中找到發(fā)生異常的時(shí)間、原因，然后根據(jù)這些信息來解決異常。 
 
5. 二進(jìn)制日志(bin log) 
binlog可以說是MySQL中比較 重要 的日志了，在日常開發(fā)及運(yùn)維過程中，經(jīng)常會(huì)遇到。 
binlog即binary log，二進(jìn)制日志文件，也叫作變更日志（update log）。它記錄了數(shù)據(jù)庫所有執(zhí)行的DD 和 DML 等數(shù)據(jù)庫更新事件的語句，但是不包含沒有修改任何數(shù)據(jù)的語句（如數(shù)據(jù)查詢語句select、show等）。 
它以事件形式記錄并保存在二進(jìn)制文件中。通過這些信息，我們可以再現(xiàn)數(shù)據(jù)更新操作的全過程。 
 
 如果想要記錄所有語句（例如，為了識別有問題的查詢)，需要使用通用查詢?nèi)罩尽?/p> 
 
binlog主要應(yīng)用場景: 

一是用于數(shù)據(jù)恢復(fù)，如果MySQL數(shù)據(jù)庫意外停止，可以通過二進(jìn)制日志文件來查看用戶執(zhí)行了哪些操作，對數(shù)據(jù)庫服務(wù)器文件做了哪些修改，然后根據(jù)二進(jìn)制日志文件中的記錄來恢復(fù)數(shù)據(jù)庫服務(wù)器。
二是用于數(shù)據(jù)復(fù)制，由于日志的延續(xù)性和時(shí)效性，master把它的二進(jìn)制日志傳遞給slaves來達(dá)到master-slave數(shù)據(jù)—致的目的。
 可以說MySQL數(shù)據(jù)庫的數(shù)據(jù)備份、主備、主主、主從都離不開binlog，需要依靠binlog來同步數(shù)據(jù)，保證數(shù)據(jù)—致性。

 
5.1 查看默認(rèn)情況 
查看記錄二進(jìn)制日志是否開啟：在MySQL8中默認(rèn)情況下，二進(jìn)制文件是開啟的。 
mysql> show variables like '%log_bin%';
+---------------------------------+-----------------------------+
| Variable_name                   | Value                       |
+---------------------------------+-----------------------------+
| log_bin                         | ON                          |
| log_bin_basename                | /var/lib/mysql/binlog       |
| log_bin_index                   | /var/lib/mysql/binlog.index |
| log_bin_trust_function_creators | OFF                         |
| log_bin_use_v1_row_events       | OFF                         |
| sql_log_bin                     | ON                          |
+---------------------------------+-----------------------------+
6 rows in set (0.00 sec)
 
log_bin_basename : 是binlog日志的基本文件名，后面會(huì)追加標(biāo)識來表示每一個(gè)文件 
log_bin_index:是binlog文件的索引文件，這個(gè)文件管理了所有的binlog文件的目錄 
log_bin_trust_function_creators: 限制存儲(chǔ)過程，前面我們已經(jīng)講過了，這是因?yàn)槎M(jìn)制日志的一個(gè)重要功能是用于主從復(fù)制，而存儲(chǔ)函數(shù)有可能導(dǎo)致主從的數(shù)據(jù)不一致。所以當(dāng)開啟二進(jìn)制日志后，需要限制存儲(chǔ)函數(shù)的創(chuàng)建、修改、調(diào)用 
log_bin_use_v1_row_events ：此只讀系統(tǒng)變量已棄用。ON表示使用版本1二進(jìn)制日志行，OFF表示使用版本2二進(jìn)制日志行(MysQL 5.6的默認(rèn)值為2)。 
每次服務(wù)重啟，都會(huì)新創(chuàng)建一個(gè)binlog 
 
5.2 日志參數(shù)設(shè)置 
方式1：永久性方式 
修改MySQL的 my.cnf 或 my.ini 文件可以設(shè)置二進(jìn)制日志的相關(guān)參數(shù)： 
[mysqld]
#啟用二進(jìn)制日志
log-bin=atguigu-bin
binlog_expire_logs_seconds=600
max_binlog_size=100M
 
 
 提示: 
 
log-bin=mysql-bin #打開日志(主機(jī)需要打開)，這個(gè)mysql-bin也可以自定義，這里也可以加上路徑，如: /home/www/mysql_bin_log/mysql-bin
binlog_expire_logs_seconds:此參數(shù)控制二進(jìn)制日志文件保留的時(shí)長，單位是秒，默認(rèn)2592000 3(天-- 14400 4小時(shí); 86400 1天; 259200 3天;
max_binlog_size:控制單個(gè)二進(jìn)制日志大小，當(dāng)前日志文件大小超過此變量時(shí)，執(zhí)行切換動(dòng)作。此參數(shù)的最大和默認(rèn)值是1GB，該設(shè)置并不能嚴(yán)格控制Binlog的大小，尤其是Binlog比較靠近最大值而又遇到一個(gè)比較大事務(wù)時(shí)，為了保證事務(wù)的完整性，可能不做切換日志的動(dòng)作，只能將該事務(wù)的所有SQL都記錄進(jìn)當(dāng)前日志，直到事務(wù)結(jié)束。一般情況下可采取默認(rèn)值

 
重新啟動(dòng)MySQL服務(wù)，查詢二進(jìn)制日志的信息，執(zhí)行結(jié)果： 
 
設(shè)置帶文件夾的bin-log日志存放目錄 
如果想改變?nèi)罩疚募哪夸浐兔Q，可以對my.cnf或my.ini中的log_bin參數(shù)修改如下： 
[mysqld]
log-bin="/var/lib/mysql/binlog/atguigu-bin"
 
注意：新建的文件夾需要使用mysql用戶，使用下面的命令即可。 
chown -R -v mysql:mysql binlog
 
重啟MySQL服務(wù)之后，新的二進(jìn)制日志文件將出現(xiàn)在/var/lib/mysql/binlog/文件夾下面: 
mysql>  show variables like '%log_bin%';
+---------------------------------+----------------------------------+
| Variable_name                   | Value                            |
+---------------------------------+----------------------------------+
| log_bin                         | ON                               |
| log_bin_basename                | /var/lib/mysql/atguigu-bin       |
| log_bin_index                   | /var/lib/mysql/atguigu-bin.index |
| log_bin_trust_function_creators | OFF                              |
| log_bin_use_v1_row_events       | OFF                              |
| sql_log_bin                     | ON                               |
+---------------------------------+----------------------------------+
6 rows in set (0.00 sec)
 
 
 提示：數(shù)據(jù)庫文件最好不要與日志文件放在同一個(gè)磁盤上! 這樣，當(dāng)數(shù)據(jù)庫文件所在的磁盤發(fā)生故障時(shí)，可以使用日志文件恢復(fù)數(shù)據(jù)。 
 
方式2：臨時(shí)性方式 
如果不希望通過修改配置文件并重啟的方式設(shè)置二進(jìn)制日志的話，還可以使用如下指令，需要注意的是在mysql8中只有 會(huì)話級別 的設(shè)置，沒有了global級別的設(shè)置。 
# global 級別
set global sql_log_bin=0;
#ERROR 1228 (HY000): Variable 'sql_log_bin' is a SESSION variable and can`t be used with SET GLOBAL

# session級別
SET sql_log_bin=0;
#Query OK, 0 rows affected (0.01 秒)
 
5.3 查看日志 
當(dāng)MySQL創(chuàng)建二進(jìn)制日志文件時(shí)，先創(chuàng)建一個(gè)以“filename”為名稱、以“.index”為后綴的文件，再創(chuàng)建一個(gè)以“filename”為名稱、以“.000001”為后綴的文件。 
MySQL服務(wù) 重新啟動(dòng)一次 ，以“.000001”為后綴的文件就會(huì)增加一個(gè)，并且后綴名按1遞增。即日志文件的個(gè)數(shù)與MySQL服務(wù)啟動(dòng)的次數(shù)相同；如果日志長度超過了 max_binlog_size 的上限（默認(rèn)是1GB），就會(huì)創(chuàng)建一個(gè)新的日志文件。 
查看當(dāng)前的二進(jìn)制日志文件列表及大小。指令如下： 
mysql> SHOW BINARY LOGS; 
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    8
Current database: *** NONE ***

+--------------------+-----------+-----------+
| Log_name           | File_size | Encrypted |
+--------------------+-----------+-----------+
| atguigu-bin.000001 |       179 | No        |
| atguigu-bin.000002 |       156 | No        |
+--------------------+-----------+-----------+
2 rows in set (0.00 sec)
 
所有對數(shù)據(jù)庫的修改都會(huì)記錄在binglog中。但binlog是二進(jìn)制文件，無法直接查看，想要更直觀的觀測它就要借助mysqlbinlog命令工具了。指令如下:在查看執(zhí)行，先執(zhí)行兩條SQL語句，如下 
insert into student(id,name,class) values(18,'Jerry','四班');
update student set name = 'Tom' where id = 15;
 
開始查看binlog 
[root@hadoop102 mysql]# mysqlbinlog "/var/lib/mysql/atguigu-bin.000002"
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#230722 16:14:20 server id 1  end_log_pos 125 CRC32 0xfbe10f64 	Start: binlog v 4, server v 8.0.25 created 230722 16:14:20 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
'/*!*/;
# at 547
#230722 16:19:02 server id 1  end_log_pos 637 CRC32 0x0e4d6052 	Query	thread_id=8	exec_time=0	error_code=0
SET TIMESTAMP=1690013942/*!*/;
BEGIN
//......
# at 776
#230722 16:19:02 server id 1  end_log_pos 807 CRC32 0x6f80cb79 	Xid = 15
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
 
執(zhí)行結(jié)果可以看到，這是一個(gè)簡單的日志文件，日志中記錄了用戶的一些操作，這里并沒有出現(xiàn)具體的SQL語句，這是因?yàn)閎inlog關(guān)鍵字后面的內(nèi)容是經(jīng)過編碼后的二進(jìn)制日志。 
這里一個(gè)update語句包含如下事件 

Query事件負(fù)責(zé)開始一個(gè)事務(wù)(BEGIN)
Table_map事件負(fù)責(zé)映射需要的表.
Update_rows事件負(fù)責(zé)寫入數(shù)據(jù)
Xid事件負(fù)責(zé)結(jié)束事務(wù)

下面命令將行事件以 偽SQL的形式 表現(xiàn)出來 
[root@hadoop102 mysql]# mysqlbinlog -v "/var/lib/mysql/atguigu-bin.000002"
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#230722 16:14:20 server id 1  end_log_pos 125 CRC32 0xfbe10f64 	Start: binlog v 4, server v 8.0.25 created 230722 16:14:20 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
3I+7ZA8BAAAAeQAAAH0AAAABAAQAOC4wLjI1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADcj7tkEwANAAgAAAAABAAEAAAAYQAEGggAAAAICAgCAAAACgoKKioAEjQA
CigBZA/h+w==
'/*!*/;
# at 125
#230722 16:14:20 server id 1  end_log_pos 156 CRC32 0x7b4b2408 	Previous-GTIDs
# [empty]
# at 156
#230722 16:18:26 server id 1  end_log_pos 235 CRC32 0x80f68688 	Anonymous_GTID	last_committed=0	sequence_number=1	rbr_only=yes	original_committed_timestamp=1690013906305153	immediate_commit_timestamp=1690013906305153	transaction_length=312
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1690013906305153 (2023-07-22 16:18:26.305153 CST)
# immediate_commit_timestamp=1690013906305153 (2023-07-22 16:18:26.305153 CST)
/*!80001 SET @@session.original_commit_timestamp=1690013906305153*//*!*/;
/*!80014 SET @@session.original_server_version=80025*//*!*/;
/*!80014 SET @@session.immediate_server_version=80025*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 235
#230722 16:18:26 server id 1  end_log_pos 316 CRC32 0x0e6498f6 	Query	thread_id=8	exec_time=0	error_code=0
SET TIMESTAMP=1690013906/*!*/;
SET @@session.pseudo_thread_id=8/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 316
#230722 16:18:26 server id 1  end_log_pos 384 CRC32 0xa3ddc17f 	Table_map: `atguigudb3`.`student` mapped to number 92
# at 384
#230722 16:18:26 server id 1  end_log_pos 437 CRC32 0x77beae88 	Write_rows: table id 92 flags: STMT_END_F

BINLOG '
0pC7ZBMBAAAARAAAAIABAAAAAFwAAAAAAAEACmF0Z3VpZ3VkYjMAB3N0dWRlbnQAAwMPDwQ8AB4A
BgEBAAIBIX/B3aM=
0pC7ZB4BAAAANQAAALUBAAAAAFwAAAAAAAEAAgAD/wASAAAABUplcnJ5BuWbm+ePrYiuvnc=
'/*!*/;
### INSERT INTO `atguigudb3`.`student`
### SET
###   @1=18
###   @2='Jerry'
###   @3='四班'
# at 437
#230722 16:18:26 server id 1  end_log_pos 468 CRC32 0x0ba33a3f 	Xid = 14
COMMIT/*!*/;
# at 468
#230722 16:19:02 server id 1  end_log_pos 547 CRC32 0xcd6ec87a 	Anonymous_GTID	last_committed=1	sequence_number=2	rbr_only=yes	original_committed_timestamp=1690013942336137	immediate_commit_timestamp=1690013942336137	transaction_length=339
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1690013942336137 (2023-07-22 16:19:02.336137 CST)
# immediate_commit_timestamp=1690013942336137 (2023-07-22 16:19:02.336137 CST)
/*!80001 SET @@session.original_commit_timestamp=1690013942336137*//*!*/;
/*!80014 SET @@session.original_server_version=80025*//*!*/;
/*!80014 SET @@session.immediate_server_version=80025*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 547
#230722 16:19:02 server id 1  end_log_pos 637 CRC32 0x0e4d6052 	Query	thread_id=8	exec_time=0	error_code=0
SET TIMESTAMP=1690013942/*!*/;
BEGIN
/*!*/;
# at 637
#230722 16:19:02 server id 1  end_log_pos 705 CRC32 0xdff84bbe 	Table_map: `atguigudb3`.`student` mapped to number 92
# at 705
#230722 16:19:02 server id 1  end_log_pos 776 CRC32 0xfbd17653 	Update_rows: table id 92 flags: STMT_END_F

BINLOG '
9pC7ZBMBAAAARAAAAMECAAAAAFwAAAAAAAEACmF0Z3VpZ3VkYjMAB3N0dWRlbnQAAwMPDwQ8AB4A
BgEBAAIBIb5L+N8=
9pC7ZB8BAAAARwAAAAgDAAAAAFwAAAAAAAEAAgAD//8ADwAAAAbotbXlha0G5LqM54+tAA8AAAAD
VG9tBuS6jOePrVN20fs=
'/*!*/;
### UPDATE `atguigudb3`.`student`
### WHERE
###   @1=15
###   @2='趙六'
###   @3='二班'
### SET
###   @1=15
###   @2='Tom'
###   @3='二班'
# at 776
#230722 16:19:02 server id 1  end_log_pos 807 CRC32 0x6f80cb79 	Xid = 15
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

 
前面的命令同時(shí)顯示binlog格式的語句，使用如下命令不顯示它 
[root@hadoop102 mysql]# mysqlbinlog -v --base64-output=DECODE-ROWS "/var/lib/mysql/atguigu-bin.000002"
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#230722 16:14:20 server id 1  end_log_pos 125 CRC32 0xfbe10f64 	Start: binlog v 4, server v 8.0.25 created 230722 16:14:20 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
# at 125
#230722 16:14:20 server id 1  end_log_pos 156 CRC32 0x7b4b2408 	Previous-GTIDs
# [empty]
# at 156
#230722 16:18:26 server id 1  end_log_pos 235 CRC32 0x80f68688 	Anonymous_GTID	last_committed=0	sequence_number=1	rbr_only=yes	original_committed_timestamp=1690013906305153	immediate_commit_timestamp=1690013906305153	transaction_length=312
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1690013906305153 (2023-07-22 16:18:26.305153 CST)
# immediate_commit_timestamp=1690013906305153 (2023-07-22 16:18:26.305153 CST)
/*!80001 SET @@session.original_commit_timestamp=1690013906305153*//*!*/;
/*!80014 SET @@session.original_server_version=80025*//*!*/;
/*!80014 SET @@session.immediate_server_version=80025*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 235
#230722 16:18:26 server id 1  end_log_pos 316 CRC32 0x0e6498f6 	Query	thread_id=8	exec_time=0	error_code=0
SET TIMESTAMP=1690013906/*!*/;
SET @@session.pseudo_thread_id=8/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 316
#230722 16:18:26 server id 1  end_log_pos 384 CRC32 0xa3ddc17f 	Table_map: `atguigudb3`.`student` mapped to number 92
# at 384
#230722 16:18:26 server id 1  end_log_pos 437 CRC32 0x77beae88 	Write_rows: table id 92 flags: STMT_END_F
### INSERT INTO `atguigudb3`.`student`
### SET
###   @1=18
###   @2='Jerry'
###   @3='四班'
# at 437
#230722 16:18:26 server id 1  end_log_pos 468 CRC32 0x0ba33a3f 	Xid = 14
COMMIT/*!*/;
# at 468
#230722 16:19:02 server id 1  end_log_pos 547 CRC32 0xcd6ec87a 	Anonymous_GTID	last_committed=1	sequence_number=2	rbr_only=yes	original_committed_timestamp=1690013942336137	immediate_commit_timestamp=1690013942336137	transaction_length=339
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1690013942336137 (2023-07-22 16:19:02.336137 CST)
# immediate_commit_timestamp=1690013942336137 (2023-07-22 16:19:02.336137 CST)
/*!80001 SET @@session.original_commit_timestamp=1690013942336137*//*!*/;
/*!80014 SET @@session.original_server_version=80025*//*!*/;
/*!80014 SET @@session.immediate_server_version=80025*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 547
#230722 16:19:02 server id 1  end_log_pos 637 CRC32 0x0e4d6052 	Query	thread_id=8	exec_time=0	error_code=0
SET TIMESTAMP=1690013942/*!*/;
BEGIN
/*!*/;
# at 637
#230722 16:19:02 server id 1  end_log_pos 705 CRC32 0xdff84bbe 	Table_map: `atguigudb3`.`student` mapped to number 92
# at 705
#230722 16:19:02 server id 1  end_log_pos 776 CRC32 0xfbd17653 	Update_rows: table id 92 flags: STMT_END_F
### UPDATE `atguigudb3`.`student`
### WHERE
###   @1=15
###   @2='趙六'
###   @3='二班'
### SET
###   @1=15
###   @2='Tom'
###   @3='二班'
# at 776
#230722 16:19:02 server id 1  end_log_pos 807 CRC32 0x6f80cb79 	Xid = 15
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
 
關(guān)于mysqlbinlog工具的使用技巧還有很多，例如只解析對某個(gè)庫的操作或者某個(gè)時(shí)間段內(nèi)的操作等。簡單分享幾個(gè)常用的語句，更多操作可以參考官方文檔。 
#  可查看參數(shù)幫助
mysqlbinlog  --no-defaults --help
#  查看最后100行
mysqlbinlog --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |tail -100
# 根據(jù)position查找
mysqlbinlog  --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |grep -A 20  '4939002'
 
上面這種辦法讀取出binlog日志的全文內(nèi)容比較多，不容易分辨查看到pos點(diǎn)信息，下面介紹一種更為方便的查詢命令： 
show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
 


IN ‘log_name’ ：指定要查詢的binlog文件名（不指定就是第一個(gè)binlog文件）

FROM pos ：指定從哪個(gè)pos起始點(diǎn)開始查起（不指定就是從整個(gè)文件首個(gè)pos點(diǎn)開始算）

LIMIT [offset]：偏移量(不指定就是0)

row_count :查詢總條數(shù)（不指定就是所有行）

mysql> show binlog events in 'atguigu-bin.000002';  
+--------------------+-----+----------------+-----------+-------------+--------------------------------------+
| Log_name           | Pos | Event_type     | Server_id | End_log_pos | Info                                 |
+--------------------+-----+----------------+-----------+-------------+--------------------------------------+
| atguigu-bin.000002 |   4 | Format_desc    |         1 |         125 | Server ver: 8.0.25, Binlog ver: 4    |
| atguigu-bin.000002 | 125 | Previous_gtids |         1 |         156 |                                      |
| atguigu-bin.000002 | 156 | Anonymous_Gtid |         1 |         235 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 235 | Query          |         1 |         316 | BEGIN                                |
| atguigu-bin.000002 | 316 | Table_map      |         1 |         384 | table_id: 92 (atguigudb3.student)    |
| atguigu-bin.000002 | 384 | Write_rows     |         1 |         437 | table_id: 92 flags: STMT_END_F       |
| atguigu-bin.000002 | 437 | Xid            |         1 |         468 | COMMIT /* xid=14 */                  |
| atguigu-bin.000002 | 468 | Anonymous_Gtid |         1 |         547 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 547 | Query          |         1 |         637 | BEGIN                                |
| atguigu-bin.000002 | 637 | Table_map      |         1 |         705 | table_id: 92 (atguigudb3.student)    |
| atguigu-bin.000002 | 705 | Update_rows    |         1 |         776 | table_id: 92 flags: STMT_END_F       |
| atguigu-bin.000002 | 776 | Xid            |         1 |         807 | COMMIT /* xid=15 */                  |
+--------------------+-----+----------------+-----------+-------------+--------------------------------------+
 
上面這條語句可以將指定的binlog日志文件，分成有效事件行的方式返回，并可使用limit指定pos點(diǎn)的起始偏移，查詢條數(shù)。其它舉例: 
#a、查詢第一個(gè)最早的binlog日志:
show binlog events\G ;

#b、指定查詢mysql-bin.088002這個(gè)文件
show binlog events in 'atguigu-bin.000002'\G;

#c、指定查詢mysql-bin.0888日2這個(gè)文件，從pos點(diǎn):391開始查起:
show binlog events in 'atguigu-bin . 088882' from 391\G;

#d、指定查詢mysql-bin.000002這個(gè)文件，從pos點(diǎn):391開始查起，查詢5條（即5條語句
show binlog events in 'atguigu-bin.080802' from 391 limit 5\G;

#e、指定查詢 mysql-bin.000002這個(gè)文件，從pos點(diǎn):391開始查起，偏移2行〈即中間跳過2個(gè)）查詢5條（即5條語句)。
show binlog events in 'atguigu-bin.088002 ' from 391 limit 2,5\G;
 
上面我們講了這么多都是基于binlog的默認(rèn)格式，binlog格式查看 
show variables like 'binlog_format';
/*
 + ---------------+-------  +
| Variable_name | Value |
 + ---------------+-------  +
| binlog_format | ROW   |
 + ---------------+-------  +
1 行于數(shù)據(jù)集 (0.02秒)
*/
 
除此之外，binlog還有2種格式，分別是Statement和Mixed 

 Statement
 每一條會(huì)修改數(shù)據(jù)的sql都會(huì)記錄在binlog中。
 優(yōu)點(diǎn)：不需要記錄每一行的變化，減少了binlog日志量，節(jié)約了IO，提高性能。
 
 Row
 5.1.5版本的MySQL才開始支持row level 的復(fù)制，它不記錄sql語句上下文相關(guān)信息，僅保存哪條記錄被修改。
 優(yōu)點(diǎn)：row level 的日志內(nèi)容會(huì)非常清楚的記錄下每一行數(shù)據(jù)修改的細(xì)節(jié)。而且不會(huì)出現(xiàn)某些特定情況下的存儲(chǔ)過程，或function，以及trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題。
 
 Mixed
 從5.1.8版本開始，MySQL提供了Mixed格式，實(shí)際上就是Statement與Row的結(jié)合。
 

詳細(xì)情況，下章講解。 
5.4 使用日志恢復(fù)數(shù)據(jù) 
如果MySQL服務(wù)器啟用了二進(jìn)制日志，在數(shù)據(jù)庫出現(xiàn)意外丟失數(shù)據(jù)時(shí)，可以使用MySQLbinlog工具從指定的時(shí)間點(diǎn)開始（例如，最后一次備份）直到現(xiàn)在或另一個(gè)指定的時(shí)間點(diǎn)的日志中恢復(fù)數(shù)據(jù)。 
mysqlbinlog恢復(fù)數(shù)據(jù)的語法如下： 
mysqlbinlog [option] filename|mysql –uuser -ppass;
 
這個(gè)命令可以這樣理解：使用mysqlbinlog命令來讀取filename中的內(nèi)容，然后使用mysql命令將這些內(nèi)容恢復(fù)到數(shù)據(jù)庫中。 


filename ：是日志文件名。

option ：可選項(xiàng)，比較重要的兩對option參數(shù)是–start-date、–stop-date 和–start-position、-- stop-position。 
  
–start-date 和 --stop-date ：可以指定恢復(fù)數(shù)據(jù)庫的起始時(shí)間點(diǎn)和結(jié)束時(shí)間點(diǎn)。
–start-position和–stop-position ：可以指定恢復(fù)數(shù)據(jù)的開始位置和結(jié)束位置。



 
 注意：使用mysqlbinlog命令進(jìn)行恢復(fù)操作時(shí)，必須是編號小的先恢復(fù)，例如atguigu-bin.000001必須在atguigu-bin.000002之前恢復(fù)。 
 
案例 
現(xiàn)在對student表有以下操作 
mysql> use atguigudb3;
Database changed
mysql> select * from student;
+----+---------+--------+
| id | name    | class  |
+----+---------+--------+
|  1 | 張三2   | 一班   |
|  3 | 李四1   | 一班   |
|  6 | Jane    | 一班   |
|  8 | 王五    | 二班   |
| 15 | Tom     | 二班   |
| 18 | Jerry   | 四班   |
| 20 | 錢七    | 三班   |
+----+---------+--------+
7 rows in set (0.00 sec)

#插入數(shù)據(jù)
mysql> insert into student(id,name,class) values(21,'aaa','No1');
Query OK, 1 row affected (0.00 sec)

mysql> insert into student(id,name,class) values(22,'aaa','No1');
Query OK, 1 row affected (0.00 sec)

mysql> insert into student(id,name,class) values(23,'aaa','No1');
Query OK, 1 row affected (0.00 sec)

mysql> select * from student;
+----+---------+--------+
| id | name    | class  |
+----+---------+--------+
|  1 | 張三2   | 一班   |
|  3 | 李四1   | 一班   |
|  6 | Jane    | 一班   |
|  8 | 王五    | 二班   |
| 15 | Tom     | 二班   |
| 18 | Jerry   | 四班   |
| 20 | 錢七    | 三班   |
| 21 | aaa     | No1    |
| 22 | aaa     | No1    |
| 23 | aaa     | No1    |
+----+---------+--------+
10 rows in set (0.01 sec)

mysql> delete from student where id = 21;
Query OK, 1 row affected (0.01 sec)

mysql> update student set name='bbb' where id=22;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql>  select * from student;
+----+---------+--------+
| id | name    | class  |
+----+---------+--------+
|  1 | 張三2   | 一班   |
|  3 | 李四1   | 一班   |
|  6 | Jane    | 一班   |
|  8 | 王五    | 二班   |
| 15 | Tom     | 二班   |
| 18 | Jerry   | 四班   |
| 20 | 錢七    | 三班   |
| 22 | bbb     | No1    |
| 23 | aaa     | No1    |
+----+---------+--------+
9 rows in set (0.00 sec)
 
誤操作 
mysql> delete from student where id > 21;
Query OK, 2 rows affected (0.01 sec)

mysql>  select * from student;
+----+---------+--------+
| id | name    | class  |
+----+---------+--------+
|  1 | 張三2   | 一班   |
|  3 | 李四1   | 一班   |
|  6 | Jane    | 一班   |
|  8 | 王五    | 二班   |
| 15 | Tom     | 二班   |
| 18 | Jerry   | 四班   |
| 20 | 錢七    | 三班   |
+----+---------+--------+
7 rows in set (0.00 sec)
 
嘗試恢復(fù) 
# 查看當(dāng)前數(shù)據(jù)庫的bin_log日志
mysql> show binary logs;
+--------------------+-----------+-----------+
| Log_name           | File_size | Encrypted |
+--------------------+-----------+-----------+
| atguigu-bin.000001 |       179 | No        |
| atguigu-bin.000002 |      2685 | No        |
+--------------------+-----------+-----------+
2 rows in set (0.00 sec)

#新增binlog【利用日志恢復(fù)本質(zhì)上依舊是對表進(jìn)行增刪改，仍然會(huì)產(chǎn)生bin_log日志。所以我們應(yīng)該新增一個(gè)bin_log日志，避免對用于恢復(fù)的日志00002產(chǎn)生影響】
mysql> show binary logs;
+--------------------+-----------+-----------+
| Log_name           | File_size | Encrypted |
+--------------------+-----------+-----------+
| atguigu-bin.000001 |       179 | No        |
| atguigu-bin.000002 |      2734 | No        |
| atguigu-bin.000003 |       156 | No        |
+--------------------+-----------+-----------+
3 rows in set (0.00 sec)
 
位置恢復(fù)show binlog events in 
 
查看日志發(fā)現(xiàn)，在備份數(shù)據(jù)后首先執(zhí)行的是插入數(shù)據(jù)操作，在Info信息中xid的值分別是22、23、24 (緊鄰的三項(xiàng)) 
**思路：**先恢復(fù)3個(gè)insert22 23 24，再恢復(fù)delete 26，最后update 27 
步驟1:恢復(fù)插入的數(shù)據(jù) 
#語法
[root@centos7-mysql-1 mysql]# /usr/bin/mysqlbinlog --start-position=初位置 --stop-position=初位置 --database=數(shù)據(jù)庫名 /var/lib/mysql/日志文件 | /usr/bin/mysql -uroot -p密碼 -v 數(shù)據(jù)庫名
#實(shí)戰(zhàn)
[root@hadoop102 mysql]# /usr/bin/mysqlbinlog --start-position=886 --stop-position=1728 --database=atguigudb3 /var/lib/mysql/atguigu-bin.000002 | /usr/bin/mysql -uroot -proot -v atguigudb3;
 
執(zhí)行完進(jìn)行查看，發(fā)現(xiàn)這三個(gè)插入操作已經(jīng)被恢復(fù) 
 
步驟2:恢復(fù)刪除的數(shù)據(jù) 
[root@hadoop102 mysql]# /usr/bin/mysqlbinlog --start-position=1807 --stop-position=2035 --database=atguigudb3 /var/lib/mysql/atguigu-bin.000002 | /usr/bin/mysql -uroot -proot -v atguigudb3;
 
查看結(jié)果 
 
步驟3:恢復(fù)修改的數(shù)據(jù)的數(shù)據(jù) 
[root@hadoop102 mysql]# /usr/bin/mysqlbinlog --start-position=2114 --stop-position=2365 --database=atguigudb3 /var/lib/mysql/atguigu-bin.000002 | /usr/bin/mysql -uroot -proot -v atguigudb3;
 
 
可以看到最終結(jié)果和刪除數(shù)據(jù)之前的結(jié)果一樣，利用binlog實(shí)現(xiàn)了數(shù)據(jù)恢復(fù)。 
當(dāng)然也可以使用日期恢復(fù)，命令格式如下： 
/usr/bin/mysqlbinlog --start-datetime="2023-07-22 16:14:20” --stop-datetime="2023-07-22 16:19:02"  --database=atguigudb3 /var/lib/mysql/binlog/atguigu-bin.000002 | /usr/bin/mysql -uroot root  -v atguigudb3
 
另外，有時(shí)候可能出現(xiàn)一個(gè)事務(wù)A執(zhí)行時(shí)間過短，幾秒內(nèi)執(zhí)行完成。此時(shí)我們找到下一個(gè)事務(wù)B的開始時(shí)間和結(jié)束時(shí)間。只要恢復(fù)的時(shí)間在B結(jié)束時(shí)間之前就可以只恢復(fù)A不恢復(fù)B【只要時(shí)間不完全包含一個(gè)事務(wù)，那么此事務(wù)就不會(huì)進(jìn)行恢復(fù)~】 
# at 4
#230722 16:14:20 server id 1  end_log_pos 125 CRC32 0xfbe10f64 	Start: binlog v 4, server v 8.0.25 created 230722 16:14:20 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
'/*!*/;
# at 547
#230722 16:19:02 server id 1  end_log_pos 637 CRC32 0x0e4d6052 	Query	thread_id=8	exec_time=0	error_code=0
SET TIMESTAMP=1690013942/*!*/;
BEGIN
//......
# at 776
#230722 16:19:02 server id 1  end_log_pos 807 CRC32 0x6f80cb79 	Xid = 15
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
 
mysqlbinlog命令對于意外操作非常有效，比如因操作不當(dāng)誤刪了數(shù)據(jù)表。 
5.5 刪除二進(jìn)制日志 
MySQL的二進(jìn)制文件可以配置自動(dòng)刪除，同時(shí)MySQL也提供了安全的手動(dòng)刪除二進(jìn)制文件的方法。PURGE MASTER LOGS只刪除指定部分的二進(jìn)制日志文件， RESET MASTER刪除所有的二進(jìn)制日志文件。具體如下： 
PURGE MASTER LOGS：刪除指定日志文件
PURGE {MASTER | BINARY} LOGS TO '指定日志文件名'
PURGE {MASTER | BINARY} LOGS BEFORE '指定日期'
 
舉例:使用PURGE MASTER LOGS語句刪除創(chuàng)建時(shí)間比binlog.000005早的所有日志 
(1）多次重新啟動(dòng)MySQL服務(wù)，便于生成多個(gè)日志文件。然后用SHOW語句顯示二進(jìn)制日志文件列表 
SHOW BINARY LOGS;
 
(2）執(zhí)行PURGE MASTER LOGS語句刪除創(chuàng)建時(shí)間比binlog.oo0005早的所有日志 
PURGE MASTER LoGS TO "binlog.000005";
 
(3）顯示二進(jìn)制日志文件列表 
SHOW BINARY LOGS ;
 
比binlog.000005早的所有日志文件都已經(jīng)被刪除了。 
舉例:使用PURGE MASTER LOGS語句刪除2020年10月25號前創(chuàng)建的所有日志文件。具體步驟如下: 
(1）顯示二進(jìn)制日志文件列表 
SHOW BINARY LOGS;
 
(2）執(zhí)行mysqlbinlog命令查看二進(jìn)制日志文件binlog.000005的內(nèi)容 
mysqlbinlog --no-defaults "/var/lib/mysql/atguigu-bin.000005"
 
 
結(jié)果可以看出20230805為日志創(chuàng)建的時(shí)間，即2023年08月05日。 
(3）使用PURGE MASTER LOGs語句刪除2022年1月05日前創(chuàng)建的所有日志文件 
PURGE MASTER LoGS before "20220105";
 
(4）顯示二進(jìn)制日志文件列表 
SHOW BINARY LOGS ;
 
2023年08月05號之前的二進(jìn)制日志文件都已經(jīng)被刪除，最后一個(gè)沒有刪除，是因?yàn)楫?dāng)前在用，還未記錄最后的時(shí)間，所以未被刪除。 
2.RESET MASTER:刪除所有二進(jìn)制日志文件 
使用RESET MASTER語句，清空所有的binlog日志。MySQL會(huì)重新創(chuàng)建二進(jìn)制文件，新的日志文件擴(kuò)展名將重新從000001開始編號。慎用! 
舉例:使用RESET MASTER語句刪除所有日志文件。 
(1）重啟MySQL服務(wù)若干次，執(zhí)行SHOW語句顯示二進(jìn)制日志文件列表。 
SHOW BINARY LOGS;
 
(2)執(zhí)行RESET MASTER語句，刪除所有日志文件 
RESET MASTER;
 
執(zhí)行完該語句后，原來的所有二進(jìn)制日志已經(jīng)全部被刪除。 
5.6 其它場景 
二進(jìn)制日志可以通過數(shù)據(jù)庫的全量備份和二進(jìn)制日志中保存的增量信息 ，完成數(shù)據(jù)庫的無損失恢復(fù) 。但是，如果遇到數(shù)據(jù)量大、數(shù)據(jù)庫和數(shù)據(jù)表很多（比如分庫分表的應(yīng)用）的場景，用二進(jìn)制日志進(jìn)行數(shù)據(jù)恢復(fù)，是很有挑戰(zhàn)性的，因?yàn)槠鹬刮恢貌蝗菀坠芾怼?/p> 
在這種情況下，一個(gè)有效的解決辦法是配置主從數(shù)據(jù)庫服務(wù)器 ，甚至是一主多從 的架構(gòu)，把二進(jìn)制日志文件的內(nèi)容通過中繼日志，同步到從數(shù)據(jù)庫服務(wù)器中，這樣就可以有效避免數(shù)據(jù)庫故障導(dǎo)致的數(shù)據(jù)異常等問題。 
6. 再談二進(jìn)制日志(binlog) 
6.1 寫入機(jī)制 
binlog的寫入時(shí)機(jī)也非常簡單，事務(wù)執(zhí)行過程中，先把日志寫到binlog cache ，事務(wù)提交的時(shí)候，再把binlog cache寫到binlog文件中。因?yàn)?mark>一個(gè)事務(wù)的binlog不能被拆開，無論這個(gè)事務(wù)多大，也要確保一次性寫入，所以系統(tǒng)會(huì)給每個(gè)線程分配一個(gè)塊內(nèi)存作為binlog cache。 
我們可以通過binlog_cache_size參數(shù)控制單個(gè)線程binlog cache大小，如果存儲(chǔ)內(nèi)容超過了這個(gè)參數(shù)，就要暫存到磁盤(Swap)。binlog日志刷盤流程如下: 
 
write和fsync的時(shí)機(jī)，可以由參數(shù)sync_binlog 控制，默認(rèn)是0 。為0的時(shí)候，表示每次提交事務(wù)都只write，由系統(tǒng)自行判斷什么時(shí)候執(zhí)行fsync。雖然性能得到提升，但是機(jī)器宕機(jī)，page cache里面的binglog 會(huì)丟失。如下圖： 
 
為了安全起見，可以設(shè)置為1 ，表示每次提交事務(wù)都會(huì)執(zhí)行fsync，就如同redo log 刷盤流程一樣。最后還有一種折中方式，可以設(shè)置為N(N>1)，表示每次提交事務(wù)都write，但累積N個(gè)事務(wù)后才fsync。 
 
在出現(xiàn)IO瓶頸的場景里，將sync_binlog設(shè)置成一個(gè)比較大的值，可以提升性能。同樣的，如果機(jī)器宕機(jī)，會(huì)丟失最近N個(gè)事務(wù)的binlog日志。 
6.2 binlog與redolog對比 

redo log 它是物理日志 ，記錄內(nèi)容是“在某個(gè)數(shù)據(jù)頁上做了什么修改”，屬于 InnoDB 存儲(chǔ)引擎層產(chǎn)生的。
而 binlog 是邏輯日志 ，記錄內(nèi)容是語句的原始邏輯，類似于“給 ID=2 這一行的 c 字段加 1”，屬于 MySQL Server層。

雖然它們都屬于持久化的保證，但是側(cè)重點(diǎn)不同： 

redo log讓InnoDB存儲(chǔ)引擎擁有了崩潰恢復(fù)能力
binlog 保證了MySQL集群架構(gòu)的數(shù)據(jù)一致性

6.3 兩階段提交 
在執(zhí)行更新語句過程，會(huì)記錄redo log與binlog兩塊日志，以基本的事務(wù)為單位，redo log在事務(wù)執(zhí)行過程中可以不斷寫入，而binlog只有在提交事務(wù)時(shí)才寫入，所以redo log與binlog的 寫入時(shí)機(jī) 不一樣 
 
redo log與binlog兩份日志之間的邏輯不一致，會(huì)出現(xiàn)什么問題？ 
以update語句為例，假設(shè)id=2的記錄，字段c值是0，把字段c值更新成1，SQL語句為update T set c=1 where id=2。 
假設(shè)執(zhí)行過程中寫完redo log日志后，binlog日志寫期間發(fā)生了異常，會(huì)出現(xiàn)什么情況呢? 
 
由于binlog沒寫完就異常，這時(shí)候binlog里面沒有對應(yīng)的修改記錄。因此，之后用binlog日志恢復(fù)數(shù)據(jù)時(shí)，就會(huì)少這一次更新，恢復(fù)出來的這一行c值是0，而原庫因?yàn)閞edo log日志恢復(fù)，這一行c值是1，最終數(shù)據(jù)不一致。 
 
為了解決兩份日志之間的邏輯一致問題，InnoDB存儲(chǔ)引擎使用兩階段提交方案。原理很簡單，將redo log的寫入拆成了兩個(gè)步驟prepare和commit，這就是兩階段提交。 
 
使用兩階段提交后，寫入binlog時(shí)發(fā)生異常也不會(huì)有影響，因?yàn)镸ySQL根據(jù)redo log日志恢復(fù)數(shù)據(jù)時(shí)，發(fā)現(xiàn)redolog還處于prepare階段，并且沒有對應(yīng)binlog日志，就會(huì)回滾該事務(wù)。 
 
另一個(gè)場景，redo log設(shè)置commit階段發(fā)生異常，那會(huì)不會(huì)回滾事務(wù)呢？ 
 
并不會(huì)回滾事務(wù)，它會(huì)執(zhí)行上圖框住的邏輯，雖然redo log是處于prepare階段，但是能通過事務(wù)id找到對應(yīng)的binlog日志，所以MySQL認(rèn)為是完整的，就會(huì)提交事務(wù)恢復(fù)數(shù)據(jù)。 
7. 中繼日志(relay log) 
7.1 介紹 
中繼日志只在主從服務(wù)器架構(gòu)的從服務(wù)器上存在。從服務(wù)器為了與主服務(wù)器保持一致，要從主服務(wù)器讀取二進(jìn)制日志的內(nèi)容，并且把讀取到的信息寫入本地的日志文件中，這個(gè)從服務(wù)器本地的日志文件就叫中繼日志。然后，從服務(wù)器讀取中繼日志，并根據(jù)中繼日志的內(nèi)容對從服務(wù)器的數(shù)據(jù)進(jìn)行更新，完成主從服務(wù)器的數(shù)據(jù)同步。 
搭建好主從服務(wù)器之后，中繼日志默認(rèn)會(huì)保存在從服務(wù)器的數(shù)據(jù)目錄下。 
文件名的格式是： 從服務(wù)器名 -relay-bin.序號 。中繼日志還有一個(gè)索引文件： 從服務(wù)器名 -relay-bin.index ，用來定位當(dāng)前正在使用的中繼日志。 
 
7.2 查看中繼日志 
中繼日志與二進(jìn)制日志的格式相同，可以用 mysqlbinlog 工具進(jìn)行查看。下面是中繼日志的一個(gè)片段： 
SET TIMESTAMP=1618558728/*!*/;
BEGIN
/*
/*!*/;
# at 950
#210416 15:38:48 server id 1  end_log_pos 832 CRC32 0xcc16d651  Table_map:
`atguigu`.`test` mapped to number 91
# at 1000
#210416 15:38:48 server id 1  end_log_pos 872 CRC32 0x07e4047c  Delete_rows: table id
91 flags: STMT_END_F  -- server id 1 是主服務(wù)器，意思是主服務(wù)器刪了一行數(shù)據(jù)
BINLOG '
CD95YBMBAAAAMgAAAEADAAAAAFsAAAAAAAEABGRlbW8ABHRlc3QAAQMAAQEBAFHWFsw=
CD95YCABAAAAKAAAAGgDAAAAAFsAAAAAAAEAAgAB/wABAAAAfATkBw==
'/*!*/;
# at 1040
*/
 
這一段的意思是，主服務(wù)器（“server id 1”）對表 atguigu.test 進(jìn)行了 2 步操作： 
定位到表 atguigu.test 編號是 91 的記錄，日志位置是 832;
刪除編號是 91 的記錄，日志位置是 872。
 
7.3 恢復(fù)的典型錯(cuò)誤 
如果從服務(wù)器宕機(jī)，有的時(shí)候?yàn)榱讼到y(tǒng)恢復(fù)，要重裝操作系統(tǒng)，這樣就可能會(huì)導(dǎo)致你的服務(wù)器名稱與之前不同 。而中繼日志里是 包含從服務(wù)器名 的。在這種情況下，就可能導(dǎo)致你恢復(fù)從服務(wù)器的時(shí)候，無法從宕機(jī)前的中繼日志里讀取數(shù)據(jù)，以為是日志文件損壞了，其實(shí)是名稱不對了。文章來源：http://www.zghlxwxcb.cn/news/detail-629961.html 
解決的方法也很簡單，把從服務(wù)器的名稱改回之前的名稱。文章來源地址http://www.zghlxwxcb.cn/news/detail-629961.html
到了這里，關(guān)于《MySQL高級篇》十五、其他數(shù)據(jù)庫日志的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！

本文來自互聯(lián)網(wǎng)用戶投稿，該文觀點(diǎn)僅代表作者本人，不代表本站立場。本站僅提供信息存儲(chǔ)空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載，請注明出處：如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實(shí)不符，請點(diǎn)擊違法舉報(bào)進(jìn)行投訴反饋，一經(jīng)查實(shí)，立即刪除！

分享到：

領(lǐng)支付寶紅包贊助服務(wù)器費(fèi)用

一百九十五、MySQL——MySQL數(shù)據(jù)庫創(chuàng)建只讀權(quán)限的賬號（附流程截圖）
在團(tuán)隊(duì)開發(fā)過程中，為了實(shí)現(xiàn)數(shù)據(jù)共享以及避免其他團(tuán)隊(duì)修改庫表數(shù)據(jù)，需要提供數(shù)據(jù)庫只讀權(quán)限的賬號，因此以MySQL數(shù)據(jù)庫為例，創(chuàng)建MySQL數(shù)據(jù)庫只讀權(quán)限的賬號以用戶名readyonly? ?密碼hurys@123為例 mysql create user \\\'readyonly\\\'@\\\'%\\\' IDENTIFIED BY \\\'hurys@123\\\'; 注意：如果創(chuàng)建用戶名時(shí)設(shè)置
2024年02月08日
瀏覽(15)
MySQL數(shù)據(jù)庫 --- 高級篇
1.1.1、連接層最上層是一些客戶端和鏈接服務(wù)，包含本地sock 通信和大多數(shù)基于客戶端/服務(wù)端工具實(shí)現(xiàn)的類似于TCP/IP的通信。主要完成一些類似于連接處理、授權(quán)認(rèn)證、及相關(guān)的安全方案。在該層上引入了線程池的概念，為通過認(rèn)證安全接入的客戶端提供線程。同樣在該層上
2024年02月08日
瀏覽(18)
MySQL數(shù)據(jù)庫高級操作
if not exists：表示檢測要?jiǎng)?chuàng)建的表是否已存在，如果不存在就繼續(xù)創(chuàng)建 int(4) zerofill：表示若數(shù)值不滿4位數(shù)，則前面用“0”填充，例0001 auto_increment：表示此字段為自增長字段，即每條記錄自動(dòng)遞增1，默認(rèn)從1開始遞增；自增長字段數(shù)據(jù)不可以重復(fù)；自增長字段必須是主鍵；如添
2024年02月09日
瀏覽(25)
MySQL數(shù)據(jù)庫高級查詢語句
基于這兩個(gè)數(shù)據(jù)庫表格來實(shí)現(xiàn)以下實(shí)驗(yàn) concat（x，y）將提供的參數(shù)x和y拼接成一個(gè)字符串 trim()返回去除指定格式的值 GROUP BY 有一個(gè)原則，凡是在 GROUP BY 后面出現(xiàn)的字段，必須在 SELECT 后面出現(xiàn)；凡是在 SELECT 后面出現(xiàn)的、且未在聚合函數(shù)中出現(xiàn)的字段，必須出現(xiàn)在 GROUP BY 后
2024年02月11日
瀏覽(97)
MySQL數(shù)據(jù)庫——高級查詢語句
數(shù)據(jù)庫是用來存儲(chǔ)數(shù)據(jù)，更新，查詢數(shù)據(jù)的工具，而查詢數(shù)據(jù)是一個(gè)數(shù)據(jù)庫最為核心的功能，數(shù)據(jù)庫是用來承載信息，而信息是用來分析和查看的。所以掌握更為精細(xì)化的查詢方式是很有必要的。本文將圍繞數(shù)據(jù)的高級查詢語句展開。 1.指定指字段進(jìn)行查詢——SELECT 語法：
2024年02月11日
瀏覽(106)
MySQL數(shù)據(jù)庫管理高級語句
復(fù)制表及內(nèi)容 ? ??克隆表獲取數(shù)據(jù)表的表結(jié)構(gòu)、索引等信息 ? ?清空表，刪除表內(nèi)的所有數(shù)據(jù) ? ? ? 刪除的特點(diǎn)：創(chuàng)建臨時(shí)表臨時(shí)表創(chuàng)建成功之后，使用SHOWTABLES命令是看不到創(chuàng)建的臨時(shí)表的，臨時(shí)表會(huì)在連接退出后被銷毀。如果在退出連接之前，也可以可執(zhí)行增刪改查
2024年02月11日
瀏覽(101)
數(shù)據(jù)庫應(yīng)用：MySQL數(shù)據(jù)庫SQL高級語句與操作
目錄一、理論 1.克隆表與清空表 2.SQL高級語句 3.SQL函數(shù) 4.SQL高級操作 5.MySQL中6種常見的約束二、實(shí)驗(yàn) ?1.克隆表與清空表 2.SQL高級語句 3.SQL函數(shù) 4.SQL高級操作 5.主鍵表和外鍵表 ?三、總結(jié) 克隆表：將數(shù)據(jù)表的數(shù)據(jù)記錄生成到新的表中。（1）克隆表 ①?先創(chuàng)建再導(dǎo)入 ②?創(chuàng)建
2024年02月13日
瀏覽(100)
Navicat遷移局域網(wǎng)內(nèi)其他PC機(jī)的MySQL數(shù)據(jù)庫
剛換了個(gè)電腦，舊電腦的MySQL數(shù)據(jù)庫太多了，轉(zhuǎn)成.sql文件，再傳輸?shù)叫码娔X上運(yùn)行，太麻煩了。于是想著能不能通過局域網(wǎng)連到我舊電腦的MySQL上，然后直接進(jìn)行數(shù)據(jù)庫遷移。 ??打開DOS命令窗口輸入IP config命令查看本機(jī)的IP。這里可以看到新電腦的IP是 192.168.1.24 。 ??然后
2024年02月01日
瀏覽(28)
k8s創(chuàng)建數(shù)據(jù)庫mysql MySQL數(shù)據(jù)庫之日志管理
?本文使用的是本機(jī)掛載數(shù)據(jù)，這樣存在一個(gè)弊端沒有pvc掛載好? 重點(diǎn)來了：這種共享宿主機(jī)存儲(chǔ)的方法似乎可以解決Mysql數(shù)據(jù)庫數(shù)據(jù)恢復(fù)的場景，我們似乎可以萬事大吉了！ But ，有的老鐵會(huì)問：如果我得宿主機(jī)掛了怎么辦？或者Pod沒有在上一次節(jié)點(diǎn)上拉起，而是在新的節(jié)點(diǎn)
2023年04月27日
瀏覽(301)
數(shù)據(jù)庫應(yīng)用：MySQL高級語句（一）
目錄一、理論 1.常用查詢 2.函數(shù) 3.進(jìn)階查詢二、實(shí)驗(yàn) 1.普通查詢 2.函數(shù) 3.進(jìn)階查詢三、問題 1.MySQL || 運(yùn)算符不生效四、總結(jié) 常用查詢包括：增、刪、改、查；對 MySQL 數(shù)據(jù)庫的查詢，除了基本的查詢外，有時(shí)候需要對查詢的結(jié)果集進(jìn)行處理。（1）selelct select，顯示表格中
2024年02月17日
瀏覽(85)