建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
mysql命令行下怎樣實(shí)現(xiàn)數(shù)據(jù)的回滾操作
當(dāng)啟動(dòng)Binlog后，事務(wù)會(huì)產(chǎn)生Binlog Event，這些Event被看做事務(wù)數(shù)據(jù)的一部分。因此要保證事務(wù)的Binlog Event和InnoDB引擎中的數(shù)據(jù)的一致性。所以帶Binlog的CrashSafe要求MySQL宕機(jī)重啟后能夠保證：
公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶(hù)真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶(hù)帶來(lái)驚喜。創(chuàng)新互聯(lián)推出當(dāng)雄免費(fèi)做網(wǎng)站回饋大家。
- 所有已經(jīng)提交的事務(wù)的數(shù)據(jù)仍然存在。
- 所有沒(méi)有提交的事務(wù)的數(shù)據(jù)自動(dòng)回滾。
- 所有已經(jīng)提交了的事務(wù)的Binlog Event也仍然存在。
- 所有沒(méi)有提交事務(wù)沒(méi)有記錄Binlog Event。
這些要求很好理解，如果重啟后數(shù)據(jù)還在，但是Binlog Event沒(méi)有了，就沒(méi)辦法復(fù)制到其他節(jié)點(diǎn)上了。如果重啟后，數(shù)據(jù)沒(méi)了，但是Binlog Event還在，那么不存在的數(shù)據(jù)就會(huì)被復(fù)制到其他節(jié)點(diǎn)上，從而導(dǎo)致主從的不一致。
為了保證帶Binlog的CrashSafe，MySQL內(nèi)部使用的兩階段提交(Two Phase Commit)。
2 - MySQL的Two Phase Commit(2PC)
在開(kāi)啟Binlog后，MySQL內(nèi)部會(huì)自動(dòng)將普通事務(wù)當(dāng)做一個(gè)XA事務(wù)來(lái)處理：
- 自動(dòng)為每個(gè)事務(wù)分配一個(gè)唯一的ID
- COMMIT會(huì)被自動(dòng)的分成Prepare和Commit兩個(gè)階段。
- Binlog會(huì)被當(dāng)做事務(wù)協(xié)調(diào)者(Transaction Coordinator)，Binlog Event會(huì)被當(dāng)做協(xié)調(diào)者日志。
想了解2PC，可以參考文檔：【?！?/p>
- 分布式事務(wù)ID(XID)
使用2PC時(shí)，MySQL會(huì)自動(dòng)的為每一個(gè)事務(wù)分配一個(gè)ID，叫XID。XID是唯一的，每個(gè)事務(wù)的XID都不相同。XID會(huì)分別被Binlog和InnoDB記入日志中，供恢復(fù)時(shí)使用。MySQ內(nèi)部的XID由三部分組成：
- 前綴部分
前綴部分是字符串"MySQLXid"
- Server ID部分
當(dāng)前MySQL的server_id
- query_id部分
為了保證XID的的唯一性，數(shù)字部分使用了query_id。MySQL內(nèi)部會(huì)自動(dòng)的為每一個(gè)語(yǔ)句分配一個(gè)query_id，全局唯一。
參考代碼：sql/xa。h的struct xid_t結(jié)構(gòu)。
- 事務(wù)的協(xié)調(diào)者Binlog
Binlog在2PC中充當(dāng)了事務(wù)的協(xié)調(diào)者（Transaction Coordinator）。由Binlog來(lái)通知InnoDB引擎來(lái)執(zhí)行prepare，commit或者rollback的步驟。事務(wù)提交的整個(gè)過(guò)程如下：
1. 協(xié)調(diào)者準(zhǔn)備階段(Prepare Phase)
告訴引擎做Prepare，InnoDB更改事務(wù)狀態(tài)，并將Redo Log刷入磁盤(pán)。
2. 協(xié)調(diào)者提交階段(Commit Phase)
2.1 記錄協(xié)調(diào)者日志，即Binlog日志。
2.2 告訴引擎做commit。
注意：記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫(xiě)入磁盤(pán))之后，這點(diǎn)至關(guān)重要。
在MySQ的代碼中將協(xié)調(diào)者叫做tc_log。在MySQL啟動(dòng)時(shí)，tc_log將被初始化為mysql_bin_log對(duì)象。參考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= mysql_bin_log;
而在事務(wù)提交時(shí)，會(huì)依次執(zhí)行：
tc_log-prepare()；
tc_log-commit()；
參考代碼：sql/binlog.cc中的ha_commit_trans()。當(dāng)mysql_bin_log是tc_log時(shí)，prepare和commit的代碼在sql/binlog.cc中：
MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；
-協(xié)調(diào)者日志Xid_log_event
作為協(xié)調(diào)者，Binlog需要將事務(wù)的XID記入日志，供恢復(fù)時(shí)使用。Xid_log_event有以下幾個(gè)特點(diǎn)：
- 僅記錄query_id
因?yàn)榍熬Y部分不變，server_id已經(jīng)記錄在Event Header中，Xid_log_event中只記錄query_id部分。
- 標(biāo)志事務(wù)的結(jié)束
在Binlog中相當(dāng)于一個(gè)事務(wù)的COMMIT語(yǔ)句。
一個(gè)事務(wù)在Binlog中看起來(lái)時(shí)這樣的：
Query_log_event("BEGIN");DML產(chǎn)生的events; Xid_log_event;
- DDL沒(méi)有BEGIN，也沒(méi)有Xid_log_event 。
- 僅InnoDB的DML會(huì)產(chǎn)生Xid_log_event
因?yàn)镸yISAM不支持2PC所以不能用Xid_log_event ，但會(huì)有COMMIT Event。
Query_log_event("BEGIN");DML產(chǎn)生的events;Query_log_event("COMMIT");
問(wèn)題：Query_log_event("COMMIT")和Xid_log_event 有不同的影響嗎？
- Xid_log_event 中的Xid可以幫助master實(shí)現(xiàn)CrashSafe。
- Slave的CrashSafe不依賴(lài)Xid_log_event
事務(wù)在Slave上重做時(shí)，會(huì)重新產(chǎn)生XID。所以Slave服務(wù)器的CrashSafe并不依賴(lài)于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作為事務(wù)的結(jié)尾，告訴Slave Applier去提交這個(gè)事務(wù)。因此二者在Slave上的影響是一樣的。
3 - 恢復(fù)(Recovery)
這個(gè)機(jī)制是如何保證MySQL的CrashSafe的呢，我們來(lái)分析一下。這里我們假設(shè)用戶(hù)設(shè)置了以下參數(shù)來(lái)保證可靠性：
- 恢復(fù)前事務(wù)的狀態(tài)
在恢復(fù)開(kāi)始前事務(wù)有以下幾種狀態(tài)：
- InnoDB中已經(jīng)提交
根據(jù)前面2PC的過(guò)程，可知Binlog中也一定記錄了該事務(wù)的的Events。所以這種事務(wù)是一致的不需要處理。
- InnoDB中是prepared狀態(tài)，Binlog中有該事務(wù)的Events。
需要通知InnoDB提交這些事務(wù)。
- InnoDB中是prepared狀態(tài)，Binlog中沒(méi)有該事務(wù)的Events。
因?yàn)锽inlog還沒(méi)記錄，需要通知InnoDB回滾這些事務(wù)。
- Before InnoDB Prepare
事務(wù)可能還沒(méi)執(zhí)行完，因此InnoDB中的狀態(tài)還沒(méi)有prepare。根據(jù)2PC的過(guò)程，Binlog中也沒(méi)有該事務(wù)的events。 需要通知InnoDB回滾這些事務(wù)。
- 恢復(fù)過(guò)程
從上面的事務(wù)狀態(tài)可以看出：恢復(fù)時(shí)事務(wù)要提交還是回滾，是由Binlog來(lái)決定的。
- 事務(wù)的Xid_log_event 存在，就要提交。
- 事務(wù)的Xid_log_event 不存在，就要回滾。
恢復(fù)的過(guò)程非常簡(jiǎn)單：
- 從Binlog中讀出所有的Xid_log_event
- 告訴InnoDB提交這些XID的事務(wù)
- InnoDB回滾其它的事務(wù)
美日記刪除怎么恢復(fù)？
方法步驟:1、打開(kāi)美篇,點(diǎn)擊右上角的三條橫線。 2、選擇作品回收站。 3、點(diǎn)擊下面的三個(gè)圓點(diǎn)。 4、點(diǎn)擊恢復(fù)即可。 以上就是小編帶來(lái)的軟件恢復(fù)刪作品方法了,
具體的恢復(fù)方法如下:
1.在手機(jī)上打開(kāi)美篇的APP軟件進(jìn)入。
2.進(jìn)入到美篇軟件APP的登錄界面以后輸入對(duì)應(yīng)的賬號(hào)和密碼登錄。
3.登錄進(jìn)入該軟件的后臺(tái)以后點(diǎn)擊右下角我的按鈕。
4.在出現(xiàn)的頁(yè)面中點(diǎn)擊右上角的三條橫線。
5、在出現(xiàn)的選項(xiàng)中選擇作品回收站進(jìn)入。
6、頁(yè)面跳轉(zhuǎn)以后可以看到之前被刪除的作品，點(diǎn)擊下面的三個(gè)原點(diǎn)。
7、在手機(jī)底部彈出的選項(xiàng)中點(diǎn)擊恢復(fù)按鈕。
如果你之前開(kāi)通了日志恢復(fù)功能才可以恢復(fù) , 不然刪除后是沒(méi)有辦法找回的哦 如果你對(duì)我的回復(fù)感到 滿意,請(qǐng)你選擇采納, 將鼓勵(lì)我們更好的為其他網(wǎng)友解答.
美日記 是印記云筆記的一款新應(yīng)用，用來(lái)…記日記，有著濃重的印記云筆記風(fēng)格，兩者也有些類(lèi)似，畢竟筆記和日記其實(shí)差不了太多。
mysql中哪種日志不能直接cat或more
前言
MySQL中有以下日志文件，分別是：
1：重做日志（redo log）
2：回滾日志（undo log）
3：二進(jìn)制日志（binlog）
4：錯(cuò)誤日志（errorlog）
5：慢查詢(xún)?nèi)罩荆╯low query log）
6：一般查詢(xún)?nèi)罩荆╣eneral log）
7：中繼日志（relay log）。
其中重做日志和回滾日志與事務(wù)操作息息相關(guān)，二進(jìn)制日志也與事務(wù)操作有一定的關(guān)系，這三種日志，對(duì)理解MySQL中的事務(wù)操作有著重要的意義。
一、重做日志（redo log）
作用：
確保事務(wù)的持久性。redo日志記錄事務(wù)執(zhí)行后的狀態(tài)，用來(lái)恢復(fù)未寫(xiě)入data file的已成功事務(wù)更新的數(shù)據(jù)。防止在發(fā)生故障的時(shí)間點(diǎn)，尚有臟頁(yè)未寫(xiě)入磁盤(pán)，在重啟mysql服務(wù)的時(shí)候，根據(jù)redo log進(jìn)行重做，從而達(dá)到事務(wù)的持久性這一特性。
內(nèi)容：
物理格式的日志，記錄的是物理數(shù)據(jù)頁(yè)面的修改的信息，其redo log是順序?qū)懭雛edo log file的物理文件中去的。
什么時(shí)候產(chǎn)生：
事務(wù)開(kāi)始之后就產(chǎn)生redo log，redo log的落盤(pán)并不是隨著事務(wù)的提交才寫(xiě)入的，而是在事務(wù)的執(zhí)行過(guò)程中，便開(kāi)始寫(xiě)入redo log文件中。
什么時(shí)候釋放：
當(dāng)對(duì)應(yīng)事務(wù)的臟頁(yè)寫(xiě)入到磁盤(pán)之后，redo log的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋）。
對(duì)應(yīng)的物理文件：
默認(rèn)情況下，對(duì)應(yīng)的物理文件位于數(shù)據(jù)庫(kù)的data目錄下的ib_logfile1ib_logfile2
innodb_log_group_home_dir 指定日志文件組所在的路徑，默認(rèn)./ ，表示在數(shù)據(jù)庫(kù)的數(shù)據(jù)目錄下。
innodb_log_files_in_group 指定重做日志文件組中文件的數(shù)量，默認(rèn)2
關(guān)于文件的大小和數(shù)量，由以下兩個(gè)參數(shù)配置：
innodb_log_file_size 重做日志文件的大小。
innodb_mirrored_log_groups 指定了日志鏡像文件組的數(shù)量，默認(rèn)1
其他：
很重要一點(diǎn)，redo log是什么時(shí)候?qū)懕P(pán)的？前面說(shuō)了是在事物開(kāi)始之后逐步寫(xiě)盤(pán)的。
之所以說(shuō)重做日志是在事務(wù)開(kāi)始之后逐步寫(xiě)入重做日志文件，而不一定是事務(wù)提交才寫(xiě)入重做日志緩存，原因就是，重做日志有一個(gè)緩存區(qū)Innodb_log_buffer，Innodb_log_buffer的默認(rèn)大小為8M(這里設(shè)置的16M),Innodb存儲(chǔ)引擎先將重做日志寫(xiě)入innodb_log_buffer中。
然后會(huì)通過(guò)以下三種方式將innodb日志緩沖區(qū)的日志刷新到磁盤(pán)
Master Thread 每秒一次執(zhí)行刷新Innodb_log_buffer到重做日志文件。
每個(gè)事務(wù)提交時(shí)會(huì)將重做日志刷新到重做日志文件。
當(dāng)重做日志緩存可用空間 少于一半時(shí)，重做日志緩存被刷新到重做日志文件
由此可以看出，重做日志通過(guò)不止一種方式寫(xiě)入到磁盤(pán)，尤其是對(duì)于第一種方式，Innodb_log_buffer到重做日志文件是Master Thread線程的定時(shí)任務(wù)。
因此重做日志的寫(xiě)盤(pán)，并不一定是隨著事務(wù)的提交才寫(xiě)入重做日志文件的，而是隨著事務(wù)的開(kāi)始，逐步開(kāi)始的。
另外引用《MySQL技術(shù)內(nèi)幕 Innodb 存儲(chǔ)引擎》（page37）上的原話：
即使某個(gè)事務(wù)還沒(méi)有提交，Innodb存儲(chǔ)引擎仍然每秒會(huì)將重做日志緩存刷新到重做日志文件。
這一點(diǎn)是必須要知道的，因?yàn)檫@可以很好地解釋再大的事務(wù)的提交（commit）的時(shí)間也是很短暫的。
二、回滾日志（undo log）
作用：
保證數(shù)據(jù)的原子性，保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個(gè)版本，可以用于回滾，同時(shí)可以提供多版本并發(fā)控制下的讀（MVCC），也即非鎖定讀
內(nèi)容：
邏輯格式的日志，在執(zhí)行undo的時(shí)候，僅僅是將數(shù)據(jù)從邏輯上恢復(fù)至事務(wù)之前的狀態(tài)，而不是從物理頁(yè)面上操作實(shí)現(xiàn)的，這一點(diǎn)是不同于redo log的。
什么時(shí)候產(chǎn)生：
事務(wù)開(kāi)始之前，將當(dāng)前是的版本生成undo log，undo 也會(huì)產(chǎn)生 redo 來(lái)保證undo log的可靠性
什么時(shí)候釋放：
當(dāng)事務(wù)提交之后，undo log并不能立馬被刪除，而是放入待清理的鏈表，由purge線程判斷是否由其他事務(wù)在使用undo段中表的上一個(gè)事務(wù)之前的版本信息，決定是否可以清理undo log的日志空間。
對(duì)應(yīng)的物理文件：
MySQL5.6之前，undo表空間位于共享表空間的回滾段中，共享表空間的默認(rèn)的名稱(chēng)是ibdata，位于數(shù)據(jù)文件目錄中。
MySQL5.6之后，undo表空間可以配置成獨(dú)立的文件，但是提前需要在配置文件中配置，完成數(shù)據(jù)庫(kù)初始化后生效且不可改變undo log文件的個(gè)數(shù)
如果初始化數(shù)據(jù)庫(kù)之前沒(méi)有進(jìn)行相關(guān)配置，那么就無(wú)法配置成獨(dú)立的表空間了。
關(guān)于MySQL5.7之后的獨(dú)立undo 表空間配置參數(shù)如下：
innodb_undo_directory = /data/undospace/ –undo獨(dú)立表空間的存放目錄 innodb_undo_logs = 128 –回滾段為128KB innodb_undo_tablespaces = 4 –指定有4個(gè)undo log文件
如果undo使用的共享表空間，這個(gè)共享表空間中又不僅僅是存儲(chǔ)了undo的信息，共享表空間的默認(rèn)為與MySQL的數(shù)據(jù)目錄下面，其屬性由參數(shù)innodb_data_file_path配置。
其他：
undo是在事務(wù)開(kāi)始之前保存的被修改數(shù)據(jù)的一個(gè)版本，產(chǎn)生undo日志的時(shí)候，同樣會(huì)伴隨類(lèi)似于保護(hù)事務(wù)持久化機(jī)制的redolog的產(chǎn)生。
默認(rèn)情況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當(dāng)數(shù)據(jù)庫(kù)中發(fā)生一些大的事務(wù)性操作的時(shí)候，要生成大量的undo信息，全部保存在共享表空間中的。
因此共享表空間可能會(huì)變的很大，默認(rèn)情況下，也就是undo 日志使用共享表空間的時(shí)候，被“撐大”的共享表空間是不會(huì)也不能自動(dòng)收縮的。
因此，mysql5.7之后的“獨(dú)立undo 表空間”的配置就顯得很有必要了。
三、二進(jìn)制日志（binlog）：
作用：
用于復(fù)制，在主從復(fù)制中，從庫(kù)利用主庫(kù)上的binlog進(jìn)行重播，實(shí)現(xiàn)主從同步。
用于數(shù)據(jù)庫(kù)的基于時(shí)間點(diǎn)的還原。
內(nèi)容：
邏輯格式的日志，可以簡(jiǎn)單認(rèn)為就是執(zhí)行過(guò)的事務(wù)中的sql語(yǔ)句。
但又不完全是sql語(yǔ)句這么簡(jiǎn)單，而是包括了執(zhí)行的sql語(yǔ)句（增刪改）反向的信息，也就意味著delete對(duì)應(yīng)著delete本身和其反向的insert；update對(duì)應(yīng)著update執(zhí)行前后的版本的信息；insert對(duì)應(yīng)著delete和insert本身的信息。
在使用mysqlbinlog解析binlog之后一些都會(huì)真相大白。
因此可以基于binlog做到類(lèi)似于oracle的閃回功能，其實(shí)都是依賴(lài)于binlog中的日志記錄。
什么時(shí)候產(chǎn)生：
事務(wù)提交的時(shí)候，一次性將事務(wù)中的sql語(yǔ)句（一個(gè)事物可能對(duì)應(yīng)多個(gè)sql語(yǔ)句）按照一定的格式記錄到binlog中。
這里與redo log很明顯的差異就是redo log并不一定是在事務(wù)提交的時(shí)候刷新到磁盤(pán)，redo log是在事務(wù)開(kāi)始之后就開(kāi)始逐步寫(xiě)入磁盤(pán)。
因此對(duì)于事務(wù)的提交，即便是較大的事務(wù)，提交（commit）都是很快的，但是在開(kāi)啟了bin_log的情況下，對(duì)于較大事務(wù)的提交，可能會(huì)變得比較慢一些。
這是因?yàn)閎inlog是在事務(wù)提交的時(shí)候一次性寫(xiě)入的造成的，這些可以通過(guò)測(cè)試驗(yàn)證。
什么時(shí)候釋放：
binlog的默認(rèn)是保持時(shí)間由參數(shù)expire_logs_days配置，也就是說(shuō)對(duì)于非活動(dòng)的日志文件，在生成時(shí)間超過(guò)expire_logs_days配置的天數(shù)之后，會(huì)被自動(dòng)刪除。
對(duì)應(yīng)的物理文件：
配置文件的路徑為log_bin_basename，binlog日志文件按照指定大小，當(dāng)日志文件達(dá)到指定的最大的大小之后，進(jìn)行滾動(dòng)更新，生成新的日志文件。
對(duì)于每個(gè)binlog日志文件，通過(guò)一個(gè)統(tǒng)一的index文件來(lái)組織。
其他：
二進(jìn)制日志的作用之一是還原數(shù)據(jù)庫(kù)的，這與redo log很類(lèi)似，很多人混淆過(guò)，但是兩者有本質(zhì)的不同
作用不同：redo log是保證事務(wù)的持久性的，是事務(wù)層面的，binlog作為還原的功能，是數(shù)據(jù)庫(kù)層面的（當(dāng)然也可以精確到事務(wù)層面的），雖然都有還原的意思，但是其保護(hù)數(shù)據(jù)的層次是不一樣的。
內(nèi)容不同：redo log是物理日志，是數(shù)據(jù)頁(yè)面的修改之后的物理記錄，binlog是邏輯日志，可以簡(jiǎn)單認(rèn)為記錄的就是sql語(yǔ)句
另外，兩者日志產(chǎn)生的時(shí)間，可以釋放的時(shí)間，在可釋放的情況下清理機(jī)制，都是完全不同的。
恢復(fù)數(shù)據(jù)時(shí)候的效率，基于物理日志的redo log恢復(fù)數(shù)據(jù)的效率要高于語(yǔ)句邏輯日志的binlog
關(guān)于事務(wù)提交時(shí)，redo log和binlog的寫(xiě)入順序，為了保證主從復(fù)制時(shí)候的主從一致（當(dāng)然也包括使用binlog進(jìn)行基于時(shí)間點(diǎn)還原的情況），是要嚴(yán)格一致的，MySQL通過(guò)兩階段提交過(guò)程來(lái)完成事務(wù)的一致性的，也即redo log和binlog的一致性的，理論上是先寫(xiě)redo log，再寫(xiě)binlog，兩個(gè)日志都提交成功（刷入磁盤(pán)），事務(wù)才算真正的完成。
四、錯(cuò)誤日志
錯(cuò)誤日志記錄著mysqld啟動(dòng)和停止,以及服務(wù)器在運(yùn)行過(guò)程中發(fā)生的錯(cuò)誤的相關(guān)信息。在默認(rèn)情況下，系統(tǒng)記錄錯(cuò)誤日志的功能是關(guān)閉的，錯(cuò)誤信息被輸出到標(biāo)準(zhǔn)錯(cuò)誤輸出。
指定日志路徑兩種方法:
編輯my.cnf 寫(xiě)入 log-error=[path]
通過(guò)命令參數(shù)錯(cuò)誤日志 mysqld_safe –user=mysql –log-error=[path]
顯示錯(cuò)誤日志的命令（如下圖所示）
五、普通查詢(xún)?nèi)罩?general query log
記錄了服務(wù)器接收到的每一個(gè)查詢(xún)或是命令，無(wú)論這些查詢(xún)或是命令是否正確甚至是否包含語(yǔ)法錯(cuò)誤，general log 都會(huì)將其記錄下來(lái) ，記錄的格式為 {Time ，Id ，Command，Argument }。也正因?yàn)閙ysql服務(wù)器需要不斷地記錄日志，開(kāi)啟General log會(huì)產(chǎn)生不小的系統(tǒng)開(kāi)銷(xiāo)。 因此，Mysql默認(rèn)是把General log關(guān)閉的。
查看日志的存放方式：show variables like ‘log_output’;
如果設(shè)置mysql set global log_output=’table’ 的話，則日志結(jié)果會(huì)記錄到名為gengera_log的表中，這表的默認(rèn)引擎都是CSV
如果設(shè)置表數(shù)據(jù)到文件set global log_output=file;
設(shè)置general log的日志文件路徑：
set global general_log_file=’/tmp/general.log’;
開(kāi)啟general log： set global general_log=on;
關(guān)閉general log： set global general_log=off;
然后在用：show global variables like ‘general_log’
六、慢查詢(xún)?nèi)罩?/p>
慢日志記錄執(zhí)行時(shí)間過(guò)長(zhǎng)和沒(méi)有使用索引的查詢(xún)語(yǔ)句，報(bào)錯(cuò)select、update、delete以及insert語(yǔ)句，慢日志只會(huì)記錄執(zhí)行成功的語(yǔ)句。
1. 查看慢查詢(xún)時(shí)間：
show variables like “l(fā)ong_query_time”;默認(rèn)10s
2. 查看慢查詢(xún)配置情況：
show status like “%slow_queries%”;
3. 查看慢查詢(xún)?nèi)罩韭窂剑?/p>
show variables like “%slow%”;
4. 開(kāi)啟慢日志
查看已經(jīng)開(kāi)啟：
MySQL觸發(fā)器怎么實(shí)現(xiàn)回滾
Mysql的觸發(fā)器和存儲(chǔ)過(guò)程一樣，都是嵌入到mysql的一段程序。
觸發(fā)器是mysql5新增的功能，目前線上鳳巢系統(tǒng)、北斗系統(tǒng)以及哥倫布系統(tǒng)使用的數(shù)據(jù)庫(kù)均是mysql5.0.45版本，很多程序比如fc-star管理端，sfrd(das)，dorado都會(huì)用到觸發(fā)器程序，實(shí)現(xiàn)對(duì)于數(shù)據(jù)庫(kù)增、刪、改引起事件的關(guān)聯(lián)操作。
cloudquery怎么閃回
一是不支持國(guó)產(chǎn)數(shù)據(jù)庫(kù)。例如它們均不支持如 達(dá)夢(mèng)數(shù)據(jù)庫(kù)、TiDB、GuassDB、GBase、OceanBase 等國(guó)產(chǎn)數(shù)據(jù)庫(kù)，在國(guó)內(nèi)企業(yè)尋求數(shù)據(jù)庫(kù)轉(zhuǎn)型的情況下，它們顯然并不合適。第二、統(tǒng)一安全入口。國(guó)內(nèi)企業(yè)的數(shù)據(jù)環(huán)境較為復(fù)雜，對(duì)于 DBA 而言，想要統(tǒng)一管理企業(yè)中的所有數(shù)據(jù)并不是件容易的事情。第三、數(shù)據(jù)權(quán)限管控不到位。對(duì)于操作人員的操作權(quán)限管控不到位及數(shù)據(jù)泄露問(wèn)題，對(duì)很多企業(yè)來(lái)說(shuō)都是老大難問(wèn)題，甚至有的企業(yè)根本沒(méi)有重視。第四、操作后的審計(jì)分析。當(dāng)開(kāi)發(fā)測(cè)試人員在操作完數(shù)據(jù)后，運(yùn)維人員較難立即審計(jì)到他們的操作行為和執(zhí)行語(yǔ)句，一旦出現(xiàn)問(wèn)題，必將會(huì)出現(xiàn)權(quán)責(zé)不清、審計(jì)不明、難以追蹤的問(wèn)題，這樣的事件我們已見(jiàn)過(guò)太多…
那么有沒(méi)有一個(gè)更高效更適合我們的工具，來(lái)幫助我們解決上述的問(wèn)題呢？這里跟大家分享一款國(guó)內(nèi)自研的統(tǒng)一數(shù)據(jù)庫(kù)管理工具 CloudQuery 來(lái)管理和操作企業(yè)中的數(shù)據(jù)庫(kù)，個(gè)人和團(tuán)隊(duì)都可以完全免費(fèi)使用。接下來(lái)我們以 CloudQuery 的 5 個(gè)功能點(diǎn)來(lái)看看它究竟如何解決這些問(wèn)題的。
Web 端統(tǒng)一數(shù)據(jù)入口，連接眾多數(shù)據(jù)庫(kù)
CloudQuery 是一個(gè)基于 Web 的數(shù)據(jù)庫(kù)管理工具，僅需要一個(gè)瀏覽器便可以登錄；支持眾多數(shù)據(jù)庫(kù)，如 Oracle、PostgreSQL、達(dá)夢(mèng)數(shù)據(jù)庫(kù)、Hive、MySQL 等，并將所有的數(shù)據(jù)庫(kù)納管到同一入口，統(tǒng)一管理數(shù)據(jù)庫(kù)使用者。既免去了運(yùn)維人員以往需針對(duì)不同數(shù)據(jù)庫(kù)打開(kāi)不同工具的麻煩，也結(jié)束了開(kāi)發(fā)者使用數(shù)據(jù)庫(kù)時(shí)雜亂無(wú)章的局面。
對(duì)開(kāi)發(fā)人員更高效便捷的數(shù)據(jù)操作
更適合國(guó)內(nèi)的開(kāi)發(fā)人員的使用習(xí)慣：清晰準(zhǔn)確的操作指向，更美觀流暢的數(shù)據(jù)操作邏輯，每次操作就如同點(diǎn)擊網(wǎng)頁(yè)一般簡(jiǎn)單。
支持 Oracle PL/SQL 編輯器：對(duì)于經(jīng)常習(xí)慣使用 PL/SQL 編輯器的朋友無(wú)需擔(dān)心，CloudQuery 已支持 PL/SQL 編輯器，相信你上手后會(huì)有不同的體驗(yàn)。
結(jié)果集篩選排序和五種格式的導(dǎo)出
閃回功能和打開(kāi)終端命令
細(xì)粒度的權(quán)限管控，把數(shù)據(jù)泄露風(fēng)險(xiǎn)降到最低
CloudQuery 系統(tǒng)權(quán)限控制
數(shù)據(jù)操作權(quán)限控制，可詳細(xì)到某個(gè)連接的某個(gè)庫(kù)的某張表的具體操作。
數(shù)據(jù)導(dǎo)出控制權(quán)限，查詢(xún)和導(dǎo)出分離。
審計(jì)分析中心，用戶(hù)一切行為及操作均有據(jù)可循
審計(jì)分析總覽，重要審計(jì)信息一覽無(wú)余。
語(yǔ)句明細(xì)審計(jì)，凡是在編輯區(qū)操作過(guò)的語(yǔ)句均可立刻找到。
用戶(hù)具體操作明細(xì)分析，用戶(hù)的在 CloudQuery 上的操作均有明確記錄。
可直接用到生產(chǎn)環(huán)境中的組織架構(gòu)和備份恢復(fù)功能
組織架構(gòu)中的用戶(hù)管理功能
系統(tǒng)數(shù)據(jù)備份和恢復(fù)功能
在MySQL上實(shí)現(xiàn)閃回查詢(xún)
author：sufei
版本：MySQL 8.0.18
說(shuō)明：本文僅僅是測(cè)試MySQL閃回查詢(xún)的效果
整個(gè)操作情況如下：
下面則是閃回查詢(xún)執(zhí)行效果
相應(yīng)dml操作報(bào)錯(cuò)，表明此時(shí)會(huì)話在閃回模式下，無(wú)法進(jìn)行dml操作。
分享標(biāo)題：mysql怎么實(shí)現(xiàn)閃回 mysql回車(chē)直接閃退怎么回事
標(biāo)題鏈接：http://www.dlmjj.cn/article/dodihsc.html
