?
This document uses PHP Chinese website manual Release
目錄
- E.1. 調(diào)試MySQL服務(wù)器
- E.1.1. 針對調(diào)試編譯MySQL
- E.1.2. 創(chuàng)建跟蹤文件
- E.1.3. 在gdb環(huán)境下調(diào)試mysqld
- E.1.4. 使用堆棧跟蹤
- E.1.5. 使用日志文件找出mysqld出錯原因
- E.1.6. 如果出現(xiàn)表格崩潰，請生成測試案例
- E.2. 測試MySQL 客戶端
- E.3. DBUG 軟件包
- E.4. 關(guān)于RTS線程的注釋
- E.5. 線程軟件包之間的差異
這個附錄幫助你把MySQL移植到其它操作系統(tǒng)。請先查看一下當(dāng)前支持操作系統(tǒng)列表。請參閱2.1.1節(jié)，“MySQL支持的操作系統(tǒng)”。如果你創(chuàng)建了一個新的MySQL移植（移植到列表上沒有的操作系統(tǒng)），請通知我們，以便我們能把這個操作系統(tǒng)列到我們網(wǎng)站上（http://www.mysql.com/），推薦給其它的用戶。
注意：如果你創(chuàng)建一個新的MySQL移植，你可以在GPL許可證下任意復(fù)制和發(fā)布它，但這不能使你成為MySQL的版權(quán)持有者。
這個服務(wù)器需要一個正在工作的POSIX 線程庫在。在Solaris 2.5 上我們使用Sun PThreads （在2.4版和更早的版本上，原生線程支持得不是很好），在Linux上，我們使用Xavier Leroy<Xavier.Leroy@inria.fr>的LinuxThreads。
對于那些對原生線程支持不好的新Unix變體，移植到其上的艱難部分大概就是移植MIT-pthreads包。請參閱mit-pthreads/README 和Programming POSIX Threads (http://www.humanfactor.com/pthreads/)。
直到MySQL 4.0.2版，MySQL發(fā)布包包括來自MIT經(jīng)過補(bǔ)丁的Chris Provenzano的Pthreads（請參閱MIT Pthreads 網(wǎng)頁http://www.mit.edu/afs/sipb/project/pthreads/ 以及http://www.mit.edu:8001/people/proven/IAP_2000/上的編程指導(dǎo)）。對于某些沒有POSIX線程的操作系統(tǒng)可能有用。請參閱2.8.5節(jié)，“MIT-pthreads 注意事項(xiàng)”。
也可能會用到另一個名為 FSU Pthreads的用戶級線程軟件包（請參閱http://moss.csc.ncsu.edu/~mueller/pthreads/）。 這個工具被用來到SCO的移植。
參閱 mysys目錄下的thr_lock.c 和thr_alarm.c 程序獲取一些關(guān)于這些問題的測試/例子。
服務(wù)器和客戶端需要一個能用的C++編譯器。我們在很多平臺上使用gcc。其它編譯器，據(jù)了解，可用的編譯器是SPARCworks, Sun Forte, Irix cc, HP-UX aCC, IBM AIX xlC_r), Intel ecc/icc 和 Compaq cxx)。
要僅編譯客戶端，請使用./configure --without-server.
現(xiàn)在不支持僅編譯服務(wù)器，也不能加這個功能，除非有人找出一個好的理由。
如果你想/需要改變?nèi)魏蜯akefile 或配置腳本，你也會需要到GNU Automake 和 Autoconf。請參閱2.8.3節(jié) ，“從開發(fā)源樹安裝”。
所有步驟需要從最基本的文件重新生成（remake）所有東西。
/bin/rm */.deps/*.P /bin/rm -f config.cache aclocal autoheader aclocal automake autoconf ./configure --with-debug=full --prefix='your installation directory' # The makefiles generated above need GNU make 3.75 or newer. # (called gmake below) gmake clean all install init-db
如果在新移植MySQL上遇到問題，最好做一些調(diào)試！請參閱E.1節(jié)，“調(diào)試MySQL服務(wù)器”。
注意：在你開始調(diào)試mysqld之前，首先要讓測試程序mysys/thr_alarm和mysys/thr_lock工作。這會確保你的線程安裝只有非常小的機(jī)會能運(yùn)行！
- E.1.1. 為調(diào)試編譯MySQL
- E.1.2. 創(chuàng)建追蹤文件
- E.1.3. 在gdb環(huán)境下調(diào)試
- E.1.4. 使用堆棧跟蹤
- E.1.5. 使用日志文件找出mysqld錯誤原因
- E.1.6. 如果發(fā)生表崩潰則做一個測試案例
如果你使用MySQL某些非常新的功能，你可以帶--skip-new參數(shù)（這個選項(xiàng)禁止掉所有新的潛在不安全的功能）或帶 --safe-mode參數(shù)（它禁止掉很多可能導(dǎo)致問題的優(yōu)化設(shè)置）來運(yùn)行mysqld。 請參閱A.4.2節(jié)，“如果MySQL依舊崩潰，應(yīng)該做什么”。
如果 mysqld 不啟動，你應(yīng)該查證有沒有干擾你的設(shè)置的my.cnf文件。你可以用mysqld --print-defaults...檢查my.cnf參量，并用mysqld --no-defaults來啟動去避免它們。
如果mysqld 啟動耗盡CPU或內(nèi)存資源，或者它“掛”了起來，你可以使用 mysqladmin processlist status去找出是否有人執(zhí)行了一個占用很長時間的查詢。如果你正面臨著性能問題或新客戶端不能連 之時的問題，在某些窗口中運(yùn)行mysqladmin -i10 processlist status可能是一個好主意。
mysqladmin debug 命令把一些有關(guān)使用中的鎖，使用的內(nèi)存以及查詢使用的信息轉(zhuǎn)儲到MySQL日志文件里。這將有助于解決一些問題。即使你沒有為調(diào)試編譯MySQL，這個命令也提供一些有用的信息！
如果問題是一些表變得越來越慢，你應(yīng)該試著用PTIMIZE TABLE或myisamchk優(yōu)化表。I請參閱第5章：數(shù)據(jù)庫管理 。你也可以用EXPLAIN檢查慢 的查詢。?
對那些于你的環(huán)境是獨(dú)特的問題，你也應(yīng)該查閱這個手冊里OS規(guī)格的部分請參閱?2.12節(jié)，“操作系統(tǒng)系統(tǒng)的注意事項(xiàng)”。
如果你遇到一些非常明確的問題，你可以總是試著調(diào)試MySQL。要調(diào)試MySQL，你必須用--with-debug或--with-debug=full選項(xiàng)來配置MySQL。你可以檢查MySQL是否是通過mysqld --help來和調(diào)試一起編譯的。如果--debug標(biāo)記和選項(xiàng)一起被列出了，你就可以調(diào)試了。在這種情況mysqladmin ver下把mysqld版本列成mysql ... --debug。
如果你使用gcc 或 egcs，推薦的configure 行如下：
CC=gcc CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ --with-debug --with-extra-charsets=complex
這避免了libstdc++庫和C++異常（很多編譯器在線程代碼里有C++異常的問題）的問題，并編譯了一個支持所有字符集的MySQL版本。
如果你懷疑內(nèi)存溢出錯誤，你可以用--with-debug=full來配置MySQL，這會安裝一個內(nèi)存分配（SAFEMALLOC）檢查器?？墒牵\(yùn)行SAFEMALLOC是非常慢的，所以如果你遇到性能上的問題，你應(yīng)該 用--skip-safemalloc選項(xiàng)啟動mysqld。這樣禁止掉對調(diào)用malloc()和free()的內(nèi)存檢查。
當(dāng)你用--with-debug編譯mysqld時，如果它不再崩潰，你大致已經(jīng)在MySQL內(nèi)找到一個編譯器缺陷或計時缺陷。這種情況下，你可以試著把-g加到上面的CFLAGS和CXXFLAGS變量，并且不使用--with-debug。如果mysqld失敗，你至少可以gdb用附著上它或使用核心文件上的gdb去找出發(fā)生什么問題。
當(dāng)你為調(diào)試配置MySQL時，你就自動允許許多額外的監(jiān)視mysqld健康的安全檢查函數(shù)。如果它們發(fā)現(xiàn)一些“不期望”的事，會寫一個條目到stderr，safe_mysqld，指引這個stderr到錯誤日志！這也意味著如果MySQL發(fā)生什么意外的問題，并且你正使用一個源文件發(fā)布版本，那么你要做的第一件事就是去為調(diào)試配置MySQL?。ǖ诙率前l(fā)郵件到MySQL郵件列表請求幫助）。請參閱1.7.1.1節(jié)，“MySQL郵件列表”。請根據(jù)你使用的MySQL版本對所有缺陷報告或問題使用mysqlbug腳本！
在Windows MySQL發(fā)布包里，mysqld.exe默認(rèn)編譯為支持追蹤文件。
如果mysqld 服務(wù)器沒有啟動或者你可以快速地使其崩潰，你可以創(chuàng)建一個跟蹤文件來找出問題。
要這么做的話，你必須有一個編譯了支持調(diào)試的mysqld， 你可以通過執(zhí)行mysqld -V來檢查一下。如果版本號后面跟著-debug，它就是被編譯成支持跟蹤文件。（在 Windows中，調(diào)試服務(wù)器被命名為mysqld-debug 而不是象MySQL 4.1 那樣的mysqld ）。
如下命令，啟動帶跟蹤文件的 mysqld 服務(wù)器，跟蹤文件位于Unix上的/tmp/mysqld.trace目錄里，Windows上 的C:\mysqld.trace目錄里：
shell> mysqld --debug
在Windows上，你也可以使用--standalone參數(shù)，啟動mysqld讓它不作為服務(wù)。在控制臺窗口，使用這個命令：
C:\> mysqld-debug --debug --standalone
完畢之后，你可以使用第二個窗口中的 mysql.exe 命令行工具重新制造問題。你可以用mysqladmin shutdown命令停止mysqld服務(wù)器。
注意，跟蹤文件會變得很大！如果你想生成一個小一點(diǎn)的跟蹤文件，你可以使用類似這樣的調(diào)制選項(xiàng)：
mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace
這樣就僅把帶最感興趣標(biāo)記的信息寫進(jìn)跟蹤文件里.
如果你生成一個有關(guān)于此的缺陷報告，請只用把跟蹤文件中的相關(guān)行發(fā)送到恰當(dāng)?shù)泥]件列表去，那里關(guān)注你報告出問題的部分。如果你不能找出哪里出問題，你可以ftp上載整個跟蹤文件到ftp://ftp.mysql.com/pub/mysql/upload/，并附有完全的缺陷報告，MySQL開發(fā)人員會看到它的。
追蹤文件是由Fred Fish用DBUG軟件包生成的，請參閱E.3節(jié)，“DBUG軟件包”。
如果mysqld崩潰了，在大多數(shù)系統(tǒng)上，你也可是從gdb啟動mysqld來獲取更多信息。
Linux上，有一些老版本的gdb，如果你想要能調(diào)試mysqld線程，你必須使用run --one-threadsome。在這種情況下，你可以一次只激活一個線程。我們推薦你升級到gdb 5.1 ASAP ，這個版本上線程調(diào)試工作得更好！
NTPL 線程（Linux上的新線程庫）可能會在gdb下運(yùn)行mysqld時遇到問題。一些癥狀如下：
mysqld 在啟動過程中掛起（在它寫ready for connections之前）。
mysqld 在調(diào)用pthread_mutex_lock()或pthread_mutex_unlock()過程中崩潰。
在這種情況下你應(yīng)該在啟動gdb之前在外殼上設(shè)置如下環(huán)境變量：
LD_ASSUME_KERNEL=2.4.1 export LD_ASSUME_KERNEL
在gdb下運(yùn)行mysqld時，你應(yīng)該用--skip-stack-trace來禁止堆棧跟蹤，以便能捕獲gdb內(nèi)的段錯誤。
在MySQL 4.0.14和以上版本，你應(yīng)該對mysqld使用--gdb選項(xiàng)。 這會為SIGINT安裝一個中斷處理器（需要用^C停止mysqld來設(shè)置斷點(diǎn)），并且禁止堆棧跟蹤和核心文件處理。
當(dāng)gdb沒有給舊線程釋放內(nèi)存的整個時間里，如果你做了大量的新連接，在gdb下調(diào)試MySQL是非常困難的。你可以通過帶 -O thread_cache_size= 'max_connections +1' 啟動mysqld 來避免這個問題。在多數(shù)情況下，只使用-O thread_cache_size=5'就受益無窮了！
如果mysqld帶著SIGSEGV信號死掉了，而你想在Linux上轉(zhuǎn)儲核心，你可以帶--core-file選項(xiàng)啟動mysqld。這個核心文件可以被用來生成 向后跟蹤，它可以幫你找出mysqld 為何死掉：
shell> gdb mysqld core gdb> backtrace full gdb> exit
請參閱A.4.2節(jié)，“如果MySQL依舊崩潰，該如何去做”。
如果你在Linux上使用gdb 4.17.x 或以上版本，你應(yīng)該安裝一個帶有如下信息的 .gdb 文件到你當(dāng)前目錄：
set print sevenbit off handle SIGUSR1 nostop noprint handle SIGUSR2 nostop noprint handle SIGWAITING nostop noprint handle SIGLWP nostop noprint handle SIGPIPE nostop handle SIGALRM nostop handle SIGHUP nostop handle SIGTERM nostop noprint
如果你用gdb調(diào)試線程遇到問題，你應(yīng)該下載gdb 5.x版本并用它試一下調(diào)試。新版本的 gdb 大大改善了線程處理！
下面是如何調(diào)試mysqld的例子：
shell> gdb /usr/local/libexec/mysqld gdb> run ... backtrace full # Do this when mysqld crashes
把上面的輸入寫進(jìn)一個用mysqlbug生成的郵件里，發(fā)送到綜合MySQL郵件列表。請參閱1.7.1.1節(jié)，“MySQL 郵件列表”。
如果mysqld 掛起，你可以試著用一些諸如strace 或 /usr/proc/bin/pstack 這樣的系統(tǒng)工具連檢查mysqld 在哪里掛起。
strace /tmp/log libexec/mysqld
如果你使用 Perl DBI 接口，你可以使用trace方法或設(shè)置DBI_TRACE環(huán)境變量來打開調(diào)試信息。
在一些操作系統(tǒng)上，如果mysqld意外死掉，錯誤日志包含一個堆棧跟蹤。你可以用它來找出mysqld 在哪里（也許可能找出為什么）死掉。請參閱5.11.1節(jié)，“錯誤日志”。要獲得堆棧跟蹤，你不能用-fomit-frame-pointer 選項(xiàng)編譯mysqld 為gcc。 請參閱E.1.1節(jié)，“針對調(diào)試編譯MySQL”。
如果錯誤文件包含類似下面的一些內(nèi)容：
mysqld got signal 11; The manual section 'Debugging a MySQL server' tells you how to use a stack trace and/or the core file to produce a readable backtrace that may help in finding out why mysqld died Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack range sanity check, ok, backtrace follows 0x40077552 0x81281a0 0x8128f47 0x8127be0 0x8127995 0x8104947 0x80ff28f 0x810131b 0x80ee4bc 0x80c3c91 0x80c6b43 0x80c1fd9 0x80c1686
你可以使用如下步驟找出mysqld在什么地方出現(xiàn)問題：
復(fù)制前面的數(shù)字到一個文件，如mysqld.stack。
-
為 mysqld 服務(wù)器生成符號文件：
nm -n libexec/mysqld > /tmp/mysqld.sym
注意，多數(shù)MySQL二進(jìn)制發(fā)布包（"debug" 軟件包，包含這些信息的地方就在二進(jìn)制發(fā)布包本身之內(nèi)）帶上述文件，在其中這些文件名為mysqld.sym.gz。在這種情況下，你可以簡單地解壓縮它：
gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
-
執(zhí)行 resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack.
這個命令會打印出mysqld死在哪里。如果這個不能幫你找出mysqld為什么死掉，你應(yīng)該生成一個缺陷報告，并在缺陷報告里包含上述命令的輸出結(jié)果。
注意，盡管在多數(shù)情況下，僅有一個堆棧跟蹤不能幫助我們找出問題的原因。為了定位缺陷或找到一個大致范圍，我們在大多數(shù)情況下需要知道殺掉mysqld的查詢，并最好知道一個測試案例 ，以便我們能重復(fù)問題！請參閱1.7.1.3節(jié)，“如何報告缺陷和問題”。
注意，在帶--log選項(xiàng)啟動 mysqld之前，你應(yīng)該用myisamchk檢查所有的表。請參閱第5章：數(shù)據(jù)庫管理 .
如果 mysqld 死了或掛起，你應(yīng)該用--log啟動 mysqld 。當(dāng)mysqld 再次死掉時，你可以檢查日志文件的最后，找出殺掉mysqld的查詢。
如果你不帶文件名使用 --log ，日志被保存在名為host_name.log的數(shù)據(jù)庫目錄里。在多數(shù)情況下，日志文件中的最后一個查詢殺掉mysqld，但如果有可能，你應(yīng)該重啟mysqld并從mysq命令行工具執(zhí)行找到的查詢來驗(yàn)證一下。如果這個查詢殺掉了mysqld，你也應(yīng)該測試所有沒有完成的復(fù)雜查詢。
你也可以在所有占用長時間的SELECT聲明上用命令EXPLAIN來確認(rèn) mysqld正適當(dāng)?shù)厥褂盟饕?。請參?.2.1節(jié)，“EXPLAIN 語法（獲得關(guān)于SELECT的信息）”。
你可以帶 --log-slow-queries啟動mysqld來找出占用長時間來執(zhí)行的查詢。請參閱5.11.4節(jié) ，“緩慢查詢?nèi)罩尽薄?
如果你在錯誤日志文件（通常名為hostname.err）中發(fā)現(xiàn) mysqld restarted 字樣，你大致已經(jīng)找到導(dǎo)致mysqld的查詢。如果發(fā)生這種情況，你應(yīng)該用myisamchk檢查所有表（參閱 第5章：數(shù)據(jù)庫管理 ），并在MySQL日志文件中測試這些查詢看是否有不執(zhí)行的。如果找到這樣一個查詢，試著升級到最新的MySQL版本。如果這樣不能幫助你，你不能在mysql郵件存檔中發(fā)現(xiàn)任何相關(guān)內(nèi)容，你應(yīng)該把缺陷報告給MySQL郵件列表。郵件列表在http://lists.mysql.com/訂閱，這個地址上也有連到在線列表存檔的鏈接。
如果你已經(jīng)用myisam-recover啟動了mysqld，MySQL自動檢查并試著修復(fù)MyISAM 表，看是否它們被標(biāo)志為“未正常關(guān)閉”或“崩潰”。如果發(fā)生這種情況，MySQL在文件hostname.err 寫一個條目'Warning: Checking table ...'，后面跟著警告：如果表需要修復(fù)，請修復(fù)它。如果你遇上大量的這些錯誤而mysqld沒有意外死掉，那就是有問題了，需要進(jìn)一步調(diào)查。請參閱5.3.1節(jié)，“mysqld命令行選項(xiàng)”。
如果mysqld意外死掉，這可不是一個好兆頭，但在這種情況下不用研究Checking table...信息，而是要找出mysqld為什么死掉。
如果在一些更新命令之后，mysqld總是當(dāng)?shù)簦蛘呷绻阌龅奖黄茐牡谋?，你可以用下面的操作測試看這個缺陷是否是可重復(fù)產(chǎn)生的：
卸掉MySQL守護(hù)進(jìn)程（用mysqladmin shutdown）。
給該表做備份（防止修復(fù)操作反而搞壞這種很不可能出現(xiàn)的情況）。
用 myisamchk -s database/*.MYI 檢查所有的表，用myisamchk -r database/table.MYI修理有錯誤的表。
對該表做第二次備份。
如果需要更多的空間就從MySQL數(shù)據(jù)庫目錄刪除（或移走）舊日志文件。
帶--log-bin啟動Start mysqld 。請參閱5.11.3節(jié)，“二進(jìn)制日志”。如果你想找出搞垮mysqld的查詢，你應(yīng)該使用use --log --log-bin。
當(dāng)你已經(jīng)遭遇一個被破壞的表時，請停止mysqld server 。
還原備份。
不帶--log-bin重啟動mysqld 服務(wù)器。?
重新執(zhí)行mysqlbinlog update-log-file | mysql命令。更新的日志用名字hostname-bin.#保存在MySQL數(shù)據(jù)庫目錄下。
如果該表再次被破壞，或者你可用上訴命令讓mysqld 死掉，你就已經(jīng)找到可重復(fù)產(chǎn)生的缺陷，它應(yīng)該很容易被修復(fù)！可以ftp上傳表和二進(jìn)制日志到 ftp://ftp.mysql.com/pub/mysql/upload/ 然后把它輸入我們在 http://bugs.mysql.com/上的缺陷系統(tǒng)。（請注意，/pub/mysql/upload/ 在FTP時是不可以列出（內(nèi)容）的，所以不能在FTP客戶端看見你已經(jīng)上載的東西。）如果你是一個支持客戶，你可以使用 MySQL客戶支持中心https://support.mysql.com/ 來 提醒MySQL 技術(shù)人員這個問題，讓這個問題盡快得到解決。
如果你想縮小問題的范圍，你也可以使用 mysql_find_rows腳本來只執(zhí)行一些 更新語句。
為能夠用集成的調(diào)試軟件包調(diào)試MySQL客戶端 ，你應(yīng)該用--with-debug或--with-debug=full配置MySQL。請參閱2.8.2節(jié)，“典型的配置選項(xiàng)”。
在運(yùn)行客戶端之前，你應(yīng)該設(shè)置 MYSQL_DEBUG環(huán)境變量：
shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace shell> export MYSQL_DEBUG
這會導(dǎo)致客戶端在 /tmp/client.trace目錄產(chǎn)生一個跟蹤文件。
如果你自己的客戶端代碼有問題，你應(yīng)該試著連接到服務(wù)器，用已知可用的客戶端運(yùn)行你的查詢。在調(diào)試模式下，按下面命令運(yùn)行（假設(shè)你已經(jīng)帶調(diào)試編譯了MySQL）：
shell> mysql --debug=d:t:O,/tmp/client.trace
萬一你要發(fā)送一個缺陷報告郵件，這會提供給你有用的信息。請查閱“如何報告缺陷或問題”。
如果你的客戶端在一些看起來合法的代碼處崩潰了，你應(yīng)該檢查你的mysql.h文件是否包括匹配你的MySQL庫文件。一個常見的錯誤就是用新的版本的MySQL庫使用一個來自老版本安裝的mysql.h文件。
MySQL服務(wù)器和多數(shù)MySQL客戶端都帶著由Fred Fish初創(chuàng)的DBUG 軟件包編譯成的。當(dāng)你為調(diào)試配置MytSQL之時，這個軟件使你可以得到一個程序正在調(diào)試什么的跟蹤文件。請參閱E.1.2節(jié)，“創(chuàng)建跟蹤文件”。
這一節(jié)總結(jié)了你對已建立支持調(diào)試的MySQL程序在命令行的調(diào)試選項(xiàng)處可以指定的參量值。要獲取更多使用DBUG軟件包來編程的信息，請參閱MySQL源發(fā)布包里dbug目錄下的DBUG手冊。最好使用最近的MySQL 5.1發(fā)布包以獲得最近更新的DBUG手冊。
你通過用--debug="..."或the -#... 選項(xiàng)調(diào)用一個程序來使用調(diào)試軟件包。
多數(shù)MySQL程序有默認(rèn)的調(diào)試字符串，如果你不給--debug指定一個選項(xiàng)，就使用這個默認(rèn)的。默認(rèn)的跟蹤文件通常是/tmp/program_name.trace（在Unix上）和program_name.trace （在Windows上）。
調(diào)試字符串是一系列冒號隔開的區(qū)段，如下：
<field_1>:<field_2>:...:<field_N>
每個區(qū)段包含一個強(qiáng)制標(biāo)志字符，后面跟著已和可選的 ‘,’ 以及一列用逗號隔開的修改量：
flag[,modifier,modifier,...,modifier]
當(dāng)前被識別的標(biāo)記符號是：
| 標(biāo)記 | 描述 |
| d | 允許對當(dāng)前狀態(tài)從DBUG_<N>宏輸出?？赡芨涣嘘P(guān)鍵詞，這些關(guān)鍵詞僅對那些帶有關(guān)鍵詞的DBUG宏選擇輸出。一個空的關(guān)鍵詞列意味著對所有宏輸出。 |
| D | 在每個調(diào)試起輸出行后延遲。參量一個十分之一秒為單位來延遲的數(shù)，它受限于機(jī)器的能力。比如 -#D,20 指定一個2秒的延遲。 |
| f | 限制調(diào)試和/或跟蹤，以及簡單設(shè)定于列出名字的函數(shù)。注意，空列將禁止所用函數(shù)。應(yīng)該給出適當(dāng)?shù)膁 或 t 標(biāo)記，如果它們被允許了，這個標(biāo)記僅限制它們的動作。 |
| F | 對調(diào)試或跟蹤輸出的每一行識別源文件名。 |
| i | 對調(diào)試或跟蹤輸出的每一行用PID或線程ID識別進(jìn)程。 |
| g | 允許解析，創(chuàng)建名為的dbugmon.out文件，它包含可用來簡單設(shè)定程序的信息?？赡芨涣嘘P(guān)鍵詞，它們是選擇只對列中的函數(shù)做簡單設(shè)定。一個空列意味著所有函數(shù)都要考慮到。 |
| L | 為調(diào)試或跟蹤輸出的每一行識別源文件行號。 |
| n | 為調(diào)試或跟蹤輸出的每一行打印當(dāng)前函數(shù)嵌套深度。 |
| N | 給調(diào)試輸出的每一行編號。 |
| o | 重定向調(diào)試器輸出流到指定文件。默認(rèn)輸出是stderr 文件。 |
| O | 類似于 o，但是文件在每次寫操作之間被沖刷。當(dāng)需要之時，文件在每次寫操作之間被關(guān)閉然后重新打開。 |
| p | 限制調(diào)試器作用于指定進(jìn)程。為使調(diào)試器動作，一個進(jìn)程必須用DBUG_PROCESS宏來識別，且匹配列表中的一個。 |
| P | 為調(diào)試或跟蹤輸出的每一行打印當(dāng)前進(jìn)程名字。 |
| r | 當(dāng)推出一個新狀態(tài)時，不繼承前狀態(tài)的操作嵌套深度級別。當(dāng)輸出在左邊空白開始時有用。 |
| S | 在每個調(diào)試過的函數(shù)做_sanity(_file_,_line_)函數(shù)直到 _sanity() 返回不同于0的結(jié)果。（大多數(shù)的時候與safemalloc 一起用來找出內(nèi)存漏洞）。 |
| t | 允許函數(shù)調(diào)用/退出跟蹤行?？赡芨粋€給出最大跟蹤級別的數(shù)字列（只含一個修改量），超過這個數(shù)字，調(diào)試中或跟蹤中的宏不能產(chǎn)生任何輸出。 默認(rèn)為一個編譯時間選項(xiàng)。 |
可能出現(xiàn)在外殼命令行（-# 典型地被用來引入一個控制字符串到一個應(yīng)用程序中） 的調(diào)試控制字符串的一些例子如下：
-#d:t -#d:f,main,subr1:F:L:t,20 -#d,input,output,files:n -#d:t:i:O,\\mysqld.trace
在MySQL中, 打印的一般標(biāo)記是（用 d 選項(xiàng)）是 enter, exit, error, warning, info, 和 loop 。
我曾嘗試讓MySQL使用RTS線程軟件包，但是在下面的問題上遇到阻礙：
RTS線程軟件包很多老版本的POSIX調(diào)用，對所有函數(shù)的寫封裝就很枯燥。我傾向于認(rèn)為把線程庫換成最新的POSIX規(guī)格，會更容易些。。
一些封裝正在編寫中。更多信息請參閱mysys/my_pthread.c 文件。
至少下面說道的應(yīng)該改變一下：
pthread_get_specific該使用一個參量。 sigwait應(yīng)該使用兩個參量。很多函數(shù)（至少pthread_cond_wait, pthread_cond_timedwait()）應(yīng)該返回錯誤的錯誤代碼。現(xiàn)在它們返回 -1 且設(shè)置 errno。
另一個問題是，用戶級線程使用ALRM信號，這會終止很多函數(shù)（read, write, open...）。MySQL應(yīng)該重試一下所有這上面的中斷，但是這并非很容易去驗(yàn)證。
最大的未解決問題如下：
要獲得線程級警報，我使用pthread_cond_timedwait()改變 mysys/thr_alarm.c，讓它在警報之間等待。但是它發(fā)生EINTR錯誤，終止了。我試著調(diào)試線程庫找出為什么會出這個錯誤，但是找不到一個簡便 的解決辦法。
如果人人想要用RTS線程跑一下MySQL，我建議以下幾點(diǎn)：
把MySQL使用的函數(shù)從線程庫變到POSIX。這不會占據(jù)那么長時間。
用-DHAVE_rts_threads編譯所有庫。
編譯thr_alarm。
若在執(zhí)行中有一些小的差異，可以改變my_pthread.h和my_pthread.c來修復(fù)它們。
-
運(yùn)行thr_alarm。如果它沒有任何警告，錯誤或終止信息地運(yùn)行，你就做對了。這里是一個在Solaris成功運(yùn)行的例子：
Main thread: 1 Thread 0 (5) started Thread: 5 Waiting process_alarm Thread 1 (6) started Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 1 (1) sec Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 2 (2) sec Thread: 6 Simulation of no alarm needed Thread: 6 Slept for 0 (3) sec Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 4 (4) sec Thread: 6 Waiting process_alarm thread_alarm Thread: 5 Slept for 10 (10) sec Thread: 5 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 5 (5) sec Thread: 6 Waiting process_alarm process_alarm ... thread_alarm Thread: 5 Slept for 0 (1) sec end
MySQL非常依賴使用中的線程軟件包。 所以當(dāng)為MySQL選擇一個好平臺的時候，線程軟件包就非常重要。
至少有三種線程軟件包：
用戶線程在單個進(jìn)程中。線程切換用警報管理，線程庫用鎖管理所有非線程安全函數(shù)。讀，寫和選擇操作通常被線程專有的切換器管理， 如果運(yùn)行中的線程要等待數(shù)據(jù)，這個切換器就會切換操作到另一個線程。如果用戶線程軟件包集成在標(biāo)準(zhǔn)庫（FreeBSD 和 BSDI 線程軟件包）里，這樣的 線程軟件包比那些不得不映射所有不安全調(diào)用（MIT-pthreads, FSU Pthreads 和 RTS 線程軟件包）的線程軟件包需要更少的系統(tǒng)開銷。在某些環(huán)境下（如SCO），所有系統(tǒng)調(diào)用都是線程安全的，所以映射非常容易（SCO上的FSU Pthreads包）。不足之處是：所有映射的調(diào)用占用很少的時間，于是想要能處理所有的情況就相當(dāng)繁雜。有一些系統(tǒng)調(diào)用通常不被線程軟件包（類似MIT-pthreads and sockets包）處理。線程計劃不總是最優(yōu)化的。
在分離進(jìn)程中的用戶線程。線程切換是由內(nèi)核來做，且所有的數(shù)據(jù)在線程之間共享。線程軟件包管理標(biāo)準(zhǔn)線程調(diào)用，允許在線程之間共享數(shù)據(jù)。LinuxThreads包就使用這種方法。不足之處：太多進(jìn)程。線程創(chuàng)建得慢，如果一個線程死掉了，其余得線程通常就掛起來，你必須在重啟之前殺掉這些掛起的線程。線程切換開銷有些大。
內(nèi)核線程。線程切換由線程庫或內(nèi)核來做，并且非常快。一個進(jìn)程就可以了。但在一些系統(tǒng)中ps可能顯示不同線程。如果一個線程終止，整個進(jìn)程就終止了。多數(shù)系統(tǒng) 調(diào)用是線程安全的，并且只要非常小的系統(tǒng)開銷。Solaris, HP-UX, AIX 和OSF/1 都有內(nèi)核線程。
在一些系統(tǒng)中內(nèi)核線程被系統(tǒng)庫中整合用戶級線程管理。在這種情況下，線程切換只能由線程庫來做，而內(nèi)核并不是真正的“線程感知”的。
這是MySQL參考手冊的翻譯版本，關(guān)于MySQL參考手冊，請?jiān)L問dev.mysql.com。 原始參考手冊為英文版，與英文版參考手冊相比，本翻譯版可能不是最新的。