mysql日志怎么分析,mysql操作日志怎么查

如何查看MySQL數(shù)據(jù)庫的死鎖日志

如何查看MySQL數(shù)據(jù)庫的死鎖日志?

公司主營業(yè)務(wù)：成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出平南免費(fèi)做網(wǎng)站回饋大家。

1. 使用終端或命令提示符登錄到MySQL，輸入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p?

解釋：xxxx.xxx.xxx是數(shù)據(jù)庫IP地址，username是數(shù)據(jù)庫用戶名，輸入命令后，會讓你輸入username對應(yīng)的密碼，就可以登錄了

2. 如何查看MySQL數(shù)據(jù)庫的死鎖信息?

在MySQL客戶端下輸入命令：?

show engine innodb status \G;?

3. 如何定位MySQL數(shù)據(jù)庫的死鎖信息?

在打印出來的信息中找到“LATEST DETECTED DEADLOCK”一節(jié)內(nèi)容，看圖中紅線?

4. 如何分析日志，定位死鎖原因?

看3里面的圖，紫色劃線部分?

分析：?

事務(wù)1，等待?

RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，這個位置的X鎖?

事務(wù)2，持有?

RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`這個地方的S鎖?

事務(wù)2，等待這個地方的X鎖?

理論上這個事務(wù)2是可以提交的不會，死鎖，但是這個事務(wù)日志只打印最后一部分死鎖，信息，這里面隱含的條件是，事務(wù)1也持有?

RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`這個地方的S鎖，這樣，事務(wù)2不能加X鎖，同時事務(wù)1也不能加X鎖，產(chǎn)生死鎖。?

mysqlslowdump怎么分析某個數(shù)據(jù)庫的日志

一.錯誤日志 錯誤日志在Mysql數(shù)據(jù)庫中很重要，它記錄著mysqld啟動和停止，以及服務(wù)器在運(yùn)行過程中發(fā)生的任何錯誤的相關(guān)信息。 1.配置信息 --log-error=[file-name]用來指定錯誤日志存放的位置。

mysql日志 可以分析出什么

開啟MySQL日志：

找到my.ini文件

打開 log-bin="D:\log\mysql_bin"

就會生成形如：

mysql_bin.000001

mysql_bin.index

這樣的文件。

查看MySQL日志：

D:\mysql\binmysqlbinlog mysql_bin.000001

導(dǎo)出MySQL日志到文本文件：

D:\mysql\binmysqlbinlog D:\mysql\data\mysql_bin.000002 D:\b.txt

更新MySQL日志：

mysqladmin -u root -p password flush-logs

就會生成新的日志文件，序號是連接起來的，比如上一個日志文件名為：

mysql_bin.000001

執(zhí)行命令后就會生成新的日志文件：

mysql_bin.000002

MySQL的通用查詢?nèi)罩?/h2>

查詢?nèi)罩居涗?MySQL 中所有的 query,通過“—log[=fina_name]”來打開該功能。由

于記錄了所有的 query,包括所有的 select,體積比較大,開啟后對性能也有較大的影響, 所以請大家慎用該功能。 一般只用于跟蹤某些特殊的sql 性能問題才會短暫打開該功能。默認(rèn)的查詢?nèi)罩疚募麨?hostname.log。

慢查詢?nèi)罩?/p>

顧名思義,慢查詢?nèi)罩局杏涗浀氖菆?zhí)行時間較長的 query,也就是我們常說的 slow

query,通過設(shè) —log-slow-queries[=file_name]來打開該功能并設(shè)置記錄位置和文件名, 默認(rèn)文件名為 hostname-slow.log,默認(rèn)目錄也是數(shù)據(jù)目錄。

慢查詢?nèi)罩静捎玫?是簡單的文本格式, 可以通過各種文本編輯器查看其中的內(nèi)容。中其 記錄了語句執(zhí)行的時刻,執(zhí)行所消耗的時間,執(zhí)行用戶,連接主機(jī)等相關(guān)信息。MySQL 還提 供了專門用來分析滿查詢?nèi)罩镜墓ぞ叱绦騧ysqlslowdump, 用來幫助數(shù)據(jù)庫管理人員解決可 能存在的性能問題。

mysql中如何用mysqlbinlog工具將日志文件生成txt文件出來分析

MySQL 的 Binlog 記錄著 MySQL 數(shù)據(jù)庫的所有變更信息，了解 Binlog 的結(jié)構(gòu)可以幫助我們解析Binlog，甚至對 Binlog 進(jìn)行一些修改，或者說是“篡改”，例如實(shí)現(xiàn)類似于 Oracle 的 flashback 的功能，恢復(fù)誤刪除的記錄，把 update 的記錄再還原回去等。本文將帶您探討一下這些神奇功能的實(shí)現(xiàn)，您會發(fā)現(xiàn)比您想象地要簡單得多。本文指的 Binlog 是 ROW 模式的 Binlog，這也是 MySQL 8 里的默認(rèn)模式，STATEMENT 模式因?yàn)槭褂弥杏泻芏嘞拗疲F(xiàn)在用得越來越少了。

Binlog 由事件（event）組成，請注意是事件（event）不是事務(wù)（transaction），一個事務(wù)可以包含多個事件。事件描述對數(shù)據(jù)庫的修改內(nèi)容。

現(xiàn)在我們已經(jīng)了解了 Binlog 的結(jié)構(gòu)，我們可以試著修改 Binlog 里的數(shù)據(jù)。例如前面舉例的 Binlog 刪除了一條記錄，我們可以試著把這條記錄恢復(fù)，Binlog 里面有個刪除行（DELETE_ROWS_EVENT）的事件，就是這個事件刪除了記錄，這個事件和寫行（WRITE_ROWS_EVENT）的事件的數(shù)據(jù)結(jié)構(gòu)是完全一樣的，只是刪除行事件的類型是 32，寫行事件的類型是 30，我們把對應(yīng)的 Binlog 位置的 32 改成 30 即可把已經(jīng)刪除的記錄再插入回去。從前面的 “show binlog events” 里面可看到這個 DELETE_ROWS_EVENT 是從位置 378 開始的，這里的位置就是 Binlog 文件的實(shí)際位置（以字節(jié)為單位）。從事件（event）的結(jié)構(gòu)里面可以看到 type_code 是在 event 的第 5 個字節(jié)，我們寫個 Python 小程序把把第383（378+5=383）字節(jié)改成 30 即可。當(dāng)然您也可以用二進(jìn)制編輯工具來改。

找出 Binlog 中的大事務(wù)

由于 ROW 模式的 Binlog 是每一個變更都記錄一條日志，因此一個簡單的 SQL，在 Binlog 里可能會產(chǎn)生一個巨無霸的事務(wù)，例如一個不帶 where 的 update 或 delete 語句，修改了全表里面的所有記錄，每條記錄都在 Binlog 里面記錄一次，結(jié)果是一個巨大的事務(wù)記錄。這樣的大事務(wù)經(jīng)常是產(chǎn)生麻煩的根源。我的一個客戶有一次向我抱怨，一個 Binlog 前滾，滾了兩天也沒有動靜，我把那個 Binlog 解析了一下，發(fā)現(xiàn)里面有個事務(wù)產(chǎn)生了 1.4G 的記錄，修改了 66 萬條記錄！下面是一個簡單的找出 Binlog 中大事務(wù)的 Python 小程序，我們知道用 mysqlbinlog 解析的 Binlog，每個事務(wù)都是以 BEGIN 開頭，以 COMMIT 結(jié)束。我們找出 BENGIN 前面的 “# at” 的位置，檢查 COMMIT 后面的 “# at” 位置，這兩個位置相減即可計算出這個事務(wù)的大小，下面是這個 Python 程序的例子。

切割 Binlog 中的大事務(wù)

對于大的事務(wù)，MySQL 會把它分解成多個事件（注意一個是事務(wù) TRANSACTION，另一個是事件 EVENT），事件的大小由參數(shù) binlog-row-event-max-size 決定，這個參數(shù)默認(rèn)是 8K。因此我們可以把若干個事件切割成一個單獨(dú)的略小的事務(wù)

ROW 模式下，即使我們只更新了一條記錄的其中某個字段，也會記錄每個字段變更前后的值，這個行為是 binlog_row_image 參數(shù)控制的，這個參數(shù)有 3 個值，默認(rèn)為 FULL，也就是記錄列的所有修改，即使字段沒有發(fā)生變更也會記錄。這樣我們就可以實(shí)現(xiàn)類似 Oracle 的 flashback 的功能，我個人估計 MySQL 未來的版本從可能會基于 Binlog 推出這樣的功能。

了解了 Binlog 的結(jié)構(gòu)，再加上 Python 這把瑞士軍刀，我們還可以實(shí)現(xiàn)很多功能，例如我們可以統(tǒng)計哪個表被修改地最多？我們還可以把 Binlog 切割成一段一段的，然后再重組，可以靈活地進(jìn)行 MySQL 數(shù)據(jù)庫的修改和遷移等工作。

如何分析錯誤日志啊，mysql\apache\下的日志文件

錯誤日志和訪問日志一樣也是Apache的標(biāo)準(zhǔn)日志。本文分析錯誤日志的內(nèi)容，介紹如何設(shè)置和錯誤日志相關(guān)的選項(xiàng)，文檔錯誤和CGI錯誤的分類，以及如何方便地查看日志內(nèi)容，等等。

一、位置和內(nèi)容

錯誤日志無論在格式上還是在內(nèi)容上都和訪問日志不同。然而，錯誤日志和訪問日志一樣也提供豐富的信息，我們可以利用這些信息分析服務(wù)器的運(yùn)行情況、哪里出現(xiàn)了問題。

錯誤日志的文件名字是error_log，但如果是Windows平臺，則錯誤日志的文件名字是error.log。錯誤日志的位置可以通過ErrorLog指令設(shè)置：

ErrorLog logs/error.log

除非文件位置用“/”開頭，否則這個文件位置是相對于ServerRoot目錄的相對路徑。如果Apache采用默認(rèn)安裝方式安裝，那么錯誤日志的位置應(yīng)該在/usr/local/apache/logs下。但是，如果Apache用某種包管理器安裝，錯誤日志很可能在其他位置。

正如其名字所示，錯誤日志記錄了服務(wù)器運(yùn)行期間遇到的各種錯誤，以及一些普通的診斷信息，比如服務(wù)器何時啟動、何時關(guān)閉等。

我們可以設(shè)置日志文件記錄信息級別的高低，控制日志文件記錄信息的數(shù)量和類型。這是通過LogLevel指令設(shè)置的，該指令默認(rèn)設(shè)置的級別是error，即記錄稱得上錯誤的事件。有關(guān)該指令中允許設(shè)置的各種選項(xiàng)的完整清單，請參見的Apache文檔。

大多數(shù)情況下，我們在日志文件中見到的內(nèi)容分屬兩類：文檔錯誤和CGI錯誤。但是，錯誤日志中偶爾也會出現(xiàn)配置錯誤，另外還有前面提到的服務(wù)器啟動和關(guān)閉信息。

二、文檔錯誤

文檔錯誤和服務(wù)器應(yīng)答中的400系列代碼相對應(yīng)，最常見的就是404錯誤——Document Not Found（文檔沒有找到）。除了404錯誤以外，用戶身份驗(yàn)證錯誤也是一種常見的錯誤。

404錯誤在用戶請求的資源（即URL）不存在時出現(xiàn)，它可能是由于用戶輸入的URL錯誤，或者由于服務(wù)器上原來存在的文檔因故被刪除或移動。

順便說一下，按照J(rèn)akob Nielson的意見，在不提供重定向或者其他補(bǔ)救措施的情況下，我們永遠(yuǎn)不應(yīng)該移動或者刪除Web網(wǎng)站的任何資源。Nielson的更多文章，請參見。

當(dāng)用戶不能打開服務(wù)器上的文檔時，錯誤日志中出現(xiàn)的記錄如下所示：

[Fri Aug 18 22:36:26 2000] [error]

[client 192.168.1.6] File does not exist:

/usr/local/apache/bugletdocs/Img/south-korea.gif

　 可以看到，正如訪問日志access_log文件一樣，錯誤日志記錄也分成多個項(xiàng)。

錯誤記錄的開頭是日期/時間標(biāo)記，注意它們的格式和access_log中日期/時間的格式不同。access_log中的格式被稱為“標(biāo)準(zhǔn)英文格式”，這或許是歷史跟我們開的一個玩笑，但現(xiàn)在要改變它已經(jīng)太遲了。

錯誤記錄的第二項(xiàng)是當(dāng)前記錄的級別，它表明了問題的嚴(yán)重程度。這個級別信息可能是LogLevel指令的文檔中所列出的任一級別（參見前面LogLevel的鏈接），error級別處于warn級別和crit級別之間。404屬于error錯誤級別，這個級別表示確實(shí)遇到了問題，但服務(wù)器還可以運(yùn)行。

錯誤記錄的第三項(xiàng)表示用戶發(fā)出請求時所用的IP地址。

記錄的最后一項(xiàng)才是真正的錯誤信息。對于404錯誤，它還給出了完整路徑指示服務(wù)器試圖訪問的文件。當(dāng)我們料想某個文件應(yīng)該在目標(biāo)位置卻出現(xiàn)了404錯誤時，這個信息是非常有用的。此時產(chǎn)生這種錯誤的原因往往是由于服務(wù)器配置錯誤、文件實(shí)際所處的虛擬主機(jī)和我們料想的不同，或者其他一些意料不到的情況。

由于用戶身份驗(yàn)證問題而出現(xiàn)的錯誤記錄如下所示：

[Tue Apr 11 22:13:21 2000]

[error] [client 192.168.1.3] user rbowen@rcbowen.

com: authentication failure for "/cgi-bin/hirecareers/company.cgi":

password mismatch

注意，由于文檔錯誤是用戶請求的直接結(jié)果，因此它們在訪問日志中也會有相應(yīng)的記錄。

三、CGI錯誤

錯誤日志最主要的用途或許是診斷行為異常的CGI程序。為了進(jìn)一步分析和處理方便，CGI程序輸出到STDERR（Standard Error，標(biāo)準(zhǔn)錯誤設(shè)備）的所有內(nèi)容都將直接進(jìn)入錯誤日志。這意味著，任何編寫良好的CGI程序，如果出現(xiàn)了問題，錯誤日志就會告訴我們有關(guān)問題的詳細(xì)信息。

然而，把CGI程序錯誤輸出到錯誤日志也有它的缺點(diǎn)，錯誤日志中將出現(xiàn)許多沒有標(biāo)準(zhǔn)格式的內(nèi)容，這使得用錯誤日志自動分析程序從中分析出有用的信息變得相當(dāng)困難。

下面是一個例子，它是調(diào)試Perl CGI代碼時，錯誤日志中出現(xiàn)的一個錯誤記錄：

[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature

end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi

Global symbol "$rv" requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.

Global symbol "%details" requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.

Global symbol "$Config" requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.

Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi

aborted due to compilation errors.

可以看到，CGI錯誤和前面的404錯誤格式相同，包含日期/時間、錯誤級別以及客戶地址、錯誤信息。但這個CGI錯誤的錯誤信息有好幾行，這往往會干擾一些錯誤日志分析軟件的工作。

有了這個錯誤信息，即使是對Perl不太熟悉的人也能夠找出許多有關(guān)錯誤的信息，例如至少可以方便地得知是哪幾行代碼出現(xiàn)了問題。Perl在報告程序錯誤方面的機(jī)制是相當(dāng)完善的。當(dāng)然，不同的編程語言輸出到錯誤日志的信息會有所不同。

由于CGI程序運(yùn)行環(huán)境的特殊性，如果沒有錯誤日志的幫助，大多數(shù)CGI程序的錯誤都將很難解決。

有不少人在郵件列表或者新聞組中抱怨說自己有一個CGI程序，當(dāng)打開網(wǎng)頁時服務(wù)器卻返回錯誤，比如“Internal Server Error”。我們可以肯定，這些人還沒有看過服務(wù)器的錯誤日志，或者根本不知道錯誤日志的存在。決多大多數(shù)情況下，錯誤日志能夠精確地指出CGI錯誤的所在以及如何修正這個錯誤。

四、查看日志文件

我常常告訴別人說，在進(jìn)行開發(fā)的同時我會不斷地檢查服務(wù)器的日志，以便能夠立即知道哪兒出了問題。但我得到的回答卻往往是沉默。起先我以為這種沉默意味著“你當(dāng)然得這樣做”，后來我才發(fā)現(xiàn)這種沉默的真正含義是“我不知道別人的做法，但我自己是不干的。”

雖然如此，下面我們還是要看看如何方便地查看服務(wù)器日志文件。用telnet連接到服務(wù)器，然后輸入下面的命令：

tail -f /usr/local/apache/logs/error_log

　 該命令將顯示出日志文件的最后幾行內(nèi)容，如果有新的內(nèi)容加入到日志文件，它還會立即顯示出新加入的內(nèi)容。

Windows用戶也同樣可以使用這種方法，比如可以使用各種為Windows提供的Unix工具軟件包。我個人愛好一個稱為AINTX的工具，它可以在找到。

還有一種替代方法是使用下面的Perl代碼，它利用了一個稱為File::Tail的模塊：

use File::Tail;

$file=File::Tail-new("/some/log/file");

while (defined($line=$file-read)) {

print "$line";

}

無論具體采用的是哪一種方法，同時打開多個終端窗口都是一種好習(xí)慣：比如在一個窗口中顯示錯誤日志，在另一個窗口中顯示訪問日志。這樣，我們就能夠隨時獲知網(wǎng)站上發(fā)生的事情并立即予以解決。轉(zhuǎn)載

當(dāng)前標(biāo)題：mysql日志怎么分析,mysql操作日志怎么查
當(dāng)前路徑：http://m.kartarina.com/article48/hddoep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計、App設(shè)計、網(wǎng)站導(dǎo)航、ChatGPT、企業(yè)網(wǎng)站制作、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)