MySQL查詢(xún)效率很慢的問(wèn)題如何分析和解決

MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開(kāi)所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過(guò)程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長(zhǎng)。另外磁盤(pán) IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開(kāi)發(fā)庫(kù)的 HDD IOPS 較低，因此面對(duì)大量的表空間，校驗(yàn)速度就非常緩慢。另外一個(gè)發(fā)現(xiàn)，MySQL 8 下正常啟用時(shí)居然也會(huì)進(jìn)行表空間校驗(yàn)，而故障恢復(fù)時(shí)則會(huì)額外再進(jìn)行一次表空間校驗(yàn)，等于校驗(yàn)了 2 遍。不過(guò) MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過(guò) 5W 時(shí)，會(huì)啟用多線(xiàn)程掃描，加快表空間校驗(yàn)過(guò)程。

讓客戶(hù)滿(mǎn)意是我們工作的目標(biāo)，不斷超越客戶(hù)的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶(hù)，將通過(guò)不懈努力成為客戶(hù)在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名申請(qǐng)、網(wǎng)站空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、咸寧網(wǎng)站維護(hù)、網(wǎng)站推廣。

如何跳過(guò)校驗(yàn)MySQL 5.7 下有方法可以跳過(guò)崩潰恢復(fù)時(shí)的表空間校驗(yàn)過(guò)程嘛？查閱了資料，方法主要有兩種：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過(guò)表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過(guò)壞頁(yè)，就可以跳過(guò)校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過(guò)這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過(guò)程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開(kāi) N 個(gè) ibd 文件了，只需要打開(kāi)一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽(tīng)了姜老師講過(guò)使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺(jué)共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。

臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過(guò)臨時(shí)修改 validate 變量值讓 MySQL 跳過(guò)表空間驗(yàn)證過(guò)程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過(guò)表空間驗(yàn)證過(guò)程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長(zhǎng)。而以非 debug 模式運(yùn)行，則無(wú)法修改 validate 變量，想法破滅。

如何分析mysql的查詢(xún)語(yǔ)句

A、設(shè)置索引項(xiàng)，應(yīng)該是出現(xiàn)在where后面的列，或者連接字句中出現(xiàn)的列；

B、使用唯一索引，索引的基數(shù)越大，索引查詢(xún)的效果越好，舉例：查詢(xún)條件中含有索引字段和非索引字段的時(shí)候，會(huì)優(yōu)先走索引篩選出數(shù)據(jù)，然后在數(shù)據(jù)中回表過(guò)濾沒(méi)有走索引的字段，但是Mysql任務(wù)，如果索引篩選出的數(shù)據(jù)量大于20%，會(huì)認(rèn)為此時(shí)走索引效果不如全表掃描，繼而放棄索引，走全表掃描來(lái)查詢(xún)；

C、使用短索引，例如一個(gè)屬性200多位，其實(shí)索引只要?jiǎng)?chuàng)建前幾位效果會(huì)好；

D、最左原則，組合索引中，靈活運(yùn)用最左前綴；

E、不要過(guò)度使用索引，索引會(huì)占用空間，影響寫(xiě)入的速度；

詳細(xì)講解如何用SQLyog來(lái)分析MySQL數(shù)據(jù)庫(kù)

我去了相關(guān)網(wǎng)站下載，它只有384K字節(jié)大小。它把兩個(gè)文件（一個(gè)可執(zhí)行文件.exe和一個(gè)動(dòng)態(tài)鏈接庫(kù)文件.dll）安裝到C:\PRogram Files\SQLyog路徑下。然后運(yùn)行可執(zhí)行文件。 安裝后沒(méi)有必要再訪問(wèn)該網(wǎng)站了，我訪問(wèn)該網(wǎng)站是得到了一個(gè)消息，說(shuō)它的域名沒(méi)有設(shè)置（configured）、登記、或正在建設(shè)中。我不清楚這個(gè)問(wèn)題是暫時(shí)的還是一直是這樣。該軟件是免費(fèi)的，并且沒(méi)有標(biāo)志廣告（banner ads），所以它可能是一個(gè)特定的尚未最終定型的商業(yè)模型。最終可能還是要負(fù)費(fèi)的。 數(shù)據(jù)庫(kù)、表格（table）和列樹(shù)（column tree）該程序一啟動(dòng)就開(kāi)始詢(xún)問(wèn)我的登錄到MySOL服務(wù)器的口令。我只需要輸入我的服務(wù)器名字、用戶(hù)id和登錄密碼。所有其它的設(shè)置都是正確的默認(rèn)值。然后（當(dāng)我開(kāi)始其它事務(wù)、重啟幾次、睡了一會(huì)之后），我重新運(yùn)行該程序，這時(shí)只需要再次輸入我的登錄密碼。該程序沒(méi)有保存密碼的選項(xiàng)，你可以認(rèn)為這是該程序的一個(gè)bug，也可以說(shuō)是程序的保密特性。 一旦你登錄之后，界面就是很值得注意。MySOL服務(wù)器上所有的數(shù)據(jù)庫(kù)都顯示在一個(gè)樹(shù)型控件上。你只能訪問(wèn)你在登錄時(shí)授權(quán)的那個(gè)數(shù)據(jù)庫(kù)。如果你點(diǎn)開(kāi)代表授權(quán)給你的那個(gè)數(shù)據(jù)庫(kù)的樹(shù)型結(jié)構(gòu)，你就可以看到一系列代表表格的節(jié)點(diǎn)。點(diǎn)開(kāi)表格節(jié)點(diǎn)后，你就可以看到一系列顯示字段名的節(jié)點(diǎn)和另一個(gè)代表索引的節(jié)點(diǎn)集合。 索引界面絕對(duì)是個(gè)好東東，這樣你就可以CRUD查詢(xún)索引和關(guān)鍵字了。這相對(duì)前端數(shù)據(jù)庫(kù)如Microsoft access來(lái)說(shuō)是個(gè)提高。如果考慮到MySOL剛剛開(kāi)始提供對(duì)主（primary）和非相關(guān)（foreign）關(guān)鍵字關(guān)系的支持，本程序這部分的設(shè)計(jì)是很成熟的。在右下方的面板上，有四個(gè)標(biāo)簽頁(yè)，即：結(jié)果（Result）、消息（Message）、對(duì)象（Object）和歷史（History）。 有什么缺點(diǎn)？我試圖發(fā)現(xiàn)該程序的缺點(diǎn)，不過(guò)只發(fā)現(xiàn)了一個(gè)。如果你在Win32 Dependency Walker下運(yùn)行程序的.exe文件，你會(huì)發(fā)現(xiàn)它引用了COMDLG32.dll文件，而COMDLG32.dll又輪流引用AppHelp。實(shí)事上，CommDlg調(diào)用AppHelp，而當(dāng)AppHelp沒(méi)有請(qǐng)求函數(shù)時(shí)，CommDlg這么做根本就是浪費(fèi)資源。 過(guò)于簡(jiǎn)單？在SQLyog FAQ上，有一種觀點(diǎn)認(rèn)為該軟件沒(méi)有正式歸檔的必要。當(dāng)然，F(xiàn)AQ（常見(jiàn)問(wèn)題解答）本身就是一種歸檔。SQLyog的界面非常直觀。我建議你打印一份MySOL文檔（包括SQL特殊語(yǔ)法擴(kuò)展）。我就是這么做的，它只用了一個(gè)半英寸的活頁(yè)封面。 最后一步？FAQ還讓人想到一個(gè)讓人耳朵起了老繭卻又是正確的Occam's Razor準(zhǔn)則——一切超出必要的復(fù)雜性都是沒(méi)有必要的。我之所以到處“推銷(xiāo)”這個(gè)工具，就是因?yàn)樗梢詾槲覀兲峁┮粋€(gè)可以管理MySOL服務(wù)器上許多數(shù)據(jù)庫(kù)的、簡(jiǎn)單的、圖形化的界面。它的速度極快，并且它的拷貝很?。梢苑旁谝粡堒洷P(pán)上）。 SQLyog宣稱(chēng)自己是一個(gè)查詢(xún)分析器，實(shí)際上它的功能遠(yuǎn)遠(yuǎn)不止這些。

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

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

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

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

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

ErrorLog logs/error.log

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

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

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

大多數(shù)情況下，我們?cè)谌罩疚募幸?jiàn)到的內(nèi)容分屬兩類(lèi)：文檔錯(cuò)誤和CGI錯(cuò)誤。但是，錯(cuò)誤日志中偶爾也會(huì)出現(xiàn)配置錯(cuò)誤，另外還有前面提到的服務(wù)器啟動(dòng)和關(guān)閉信息。

二、文檔錯(cuò)誤

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

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

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

當(dāng)用戶(hù)不能打開(kāi)服務(wù)器上的文檔時(shí)，錯(cuò)誤日志中出現(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

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

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

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

錯(cuò)誤記錄的第三項(xiàng)表示用戶(hù)發(fā)出請(qǐng)求時(shí)所用的IP地址。

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

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

[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

注意，由于文檔錯(cuò)誤是用戶(hù)請(qǐng)求的直接結(jié)果，因此它們?cè)谠L問(wèn)日志中也會(huì)有相應(yīng)的記錄。

三、CGI錯(cuò)誤

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

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

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

[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錯(cuò)誤和前面的404錯(cuò)誤格式相同，包含日期/時(shí)間、錯(cuò)誤級(jí)別以及客戶(hù)地址、錯(cuò)誤信息。但這個(gè)CGI錯(cuò)誤的錯(cuò)誤信息有好幾行，這往往會(huì)干擾一些錯(cuò)誤日志分析軟件的工作。

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

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

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

四、查看日志文件

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

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

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

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

Windows用戶(hù)也同樣可以使用這種方法，比如可以使用各種為Windows提供的Unix工具軟件包。我個(gè)人愛(ài)好一個(gè)稱(chēng)為AINTX的工具，它可以在找到。

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

use File::Tail;

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

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

print "$line";

}

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

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

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

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

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

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

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

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

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

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

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

名稱(chēng)欄目：mysql怎么分析文件 mysql 數(shù)據(jù)分析 書(shū)
網(wǎng)站路徑：http://jinyejixie.com/article20/doddoco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、企業(yè)建站、定制開(kāi)發(fā)、商城網(wǎng)站、網(wǎng)站導(dǎo)航、外貿(mào)網(wǎng)站建設(shè)

廣告

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