### 附錄E：移植到其它系統 **目錄** [E.1. 調試MySQL服務器](#)[E.1.1. 針對調試編譯MySQL](#)[E.1.2. 創建跟蹤文件](#)[E.1.3. ** 在gdb**環境下調試**mysqld**](#)[E.1.4. 使用堆棧跟蹤](#)[E.1.5. 使用日志文件找出**mysqld**出錯原因](#)[E.1.6. 如果出現表格崩潰，請生成測試案例](#)[E.2. 測試MySQL 客戶端](#)[E.3. DBUG 軟件包](#)[E.4. 關于RTS線程的注釋](#)[E.5. 線程軟件包之間的差異](#) 這個附錄幫助你把MySQL移植到其它操作系統。請先查看一下當前支持操作系統列表。請參閱[2.1.1節，“MySQL支持的操作系統”](# "2.1.1.?Operating Systems Supported by MySQL")。如果你創建了一個新的MySQL移植（移植到列表上沒有的操作系統），請通知我們，以便我們能把這個操作系統列到我們網站上（[http://www.mysql.com/](http://www.mysql.com/)），推薦給其它的用戶。 注意：如果你創建一個新的MySQL移植，你可以在GPL許可證下任意復制和發布它，但這不能使你成為MySQL的版權持有者。 這個服務器需要一個正在工作的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/](http://www.humanfactor.com/pthreads/))。 直到MySQL 4.0.2版，MySQL發布包包括來自MIT經過補丁的Chris Provenzano的Pthreads（請參閱MIT Pthreads 網頁[http://www.mit.edu/afs/sipb/project/pthreads/](http://www.mit.edu/afs/sipb/project/pthreads/) 以及[http://www.mit.edu:8001/people/proven/IAP_2000/](http://www.mit.edu:8001/people/proven/IAP_2000/)上的編程指導）。對于某些沒有POSIX線程的操作系統可能有用。請參閱[2.8.5節，“MIT-pthreads 注意事項”](# "2.8.5.?MIT-pthreads Notes")。 也可能會用到另一個名為 FSU Pthreads的用戶級線程軟件包（請參閱[http://moss.csc.ncsu.edu/~mueller/pthreads/](http://moss.csc.ncsu.edu/~mueller/pthreads/)）。 這個工具被用來到SCO的移植。 參閱 mysys目錄下的thr_lock.c 和thr_alarm.c 程序獲取一些關于這些問題的測試/例子。 服務器和客戶端需要一個能用的C++編譯器。我們在很多平臺上使用**gcc**。其它編譯器，據了解，可用的編譯器是SPARCworks, Sun Forte, Irix **cc**, HP-UX **aCC**, IBM AIX **xlC_r**), Intel **ecc/icc** 和 Compaq **cxx**)。 要僅編譯客戶端，請使用**./configure --without-server**. 現在不支持僅編譯服務器，也不能加這個功能，除非有人找出一個好的理由。 如果你想/需要改變任何Makefile 或配置腳本，你也會需要到GNU Automake 和 Autoconf。請參閱[2.8.3節 ，“從開發源樹安裝”](# "2.8.3.?Installing from the Development Source Tree")。 所有步驟需要從最基本的文件重新生成（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上遇到問題，最好做一些調試！請參閱[E.1節，“調試MySQL服務器”](# "E.1.?Debugging a MySQL Server")。 **注意**：在你開始調試**mysqld**之前，首先要讓測試程序mysys/thr_alarm和mysys/thr_lock工作。這會確保你的線程安裝只有非常小的機會能運行！ ### E.1.?調試MySQL服務器 [E.1.1. 為調試編譯MySQL](#)[E.1.2. 創建追蹤文件](#)[E.1.3. 在**gdb**環境下調試 ](#)[E.1.4. 使用堆棧跟蹤](#)[E.1.5. 使用日志文件找出**mysqld**錯誤原因 ](#)[E.1.6. 如果發生表崩潰則做一個測試案例](#) 如果你使用MySQL某些非常新的功能，你可以帶--skip-new參數（這個選項禁止掉所有新的潛在不安全的功能）或帶 --safe-mode參數（它禁止掉很多可能導致問題的優化設置）來運行**mysqld**。 請參閱[A.4.2節，“如果MySQL依舊崩潰，應該做什么”](# "A.4.2.?What to Do If MySQL Keeps Crashing")。 如果 **mysqld** 不啟動，你應該查證有沒有干擾你的設置的my.cnf文件。你可以用**mysqld --print-defaults****...**檢查my.cnf參量，并用**mysqld --no-defaults**來啟動去避免它們。 如果**mysqld** 啟動耗盡CPU或內存資源，或者它“掛”了起來，你可以使用 **mysqladmin processlist status**去找出是否有人執行了一個占用很長時間的查詢。如果你正面臨著性能問題或新客戶端不能連 之時的問題，在某些窗口中運行**mysqladmin -i10 processlist status**可能是一個好主意。 **mysqladmin debug** 命令把一些有關使用中的鎖，使用的內存以及查詢使用的信息轉儲到MySQL日志文件里。這將有助于解決一些問題。即使你沒有為調試編譯MySQL，這個命令也提供一些有用的信息！ 如果問題是一些表變得越來越慢，你應該試著用PTIMIZE TABLE或**myisamchk**優化表。I請參閱第[5章：*數據庫管理*](# "Chapter?5.?Database Administration")。你也可以用EXPLAIN檢查慢 的查詢。? 對那些于你的環境是獨特的問題，你也應該查閱這個手冊里OS規格的部分請參閱[?2.12節，“操作系統系統的注意事項”](# "2.12.?Operating System-Specific Notes")。 ### E.1.1.?針對調試編譯MySQL 如果你遇到一些非常明確的問題，你可以總是試著調試MySQL。要調試MySQL，你必須用--with-debug或--with-debug=full選項來配置MySQL。你可以檢查MySQL是否是通過**mysqld --help**來和調試一起編譯的。如果--debug標記和選項一起被列出了，你就可以調試了。在這種情況**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版本。 如果你懷疑內存溢出錯誤，你可以用--with-debug=full來配置MySQL，這會安裝一個內存分配（SAFEMALLOC）檢查器。可是，運行SAFEMALLOC是非常慢的，所以如果你遇到性能上的問題，你應該 用--skip-safemalloc選項啟動**mysqld**。這樣禁止掉對調用malloc()和free()的內存檢查。 當你用--with-debug編譯**mysqld**時，如果它不再崩潰，你大致已經在MySQL內找到一個編譯器缺陷或計時缺陷。這種情況下，你可以試著把-g加到上面的CFLAGS和CXXFLAGS變量，并且不使用--with-debug。如果**mysqld**失敗，你至少可以**gdb**用附著上它或使用核心文件上的**gdb**去找出發生什么問題。 當你為調試配置MySQL時，你就自動允許許多額外的監視**mysqld**健康的安全檢查函數。如果它們發現一些“不期望”的事，會寫一個條目到stderr，**safe_mysqld****，**指引這個stderr到錯誤日志！這也意味著如果MySQL發生什么意外的問題，并且你正使用一個源文件發布版本，那么你要做的第一件事就是去為調試配置MySQL！（第二件事是發郵件到MySQL郵件列表請求幫助）。請參閱[1.7.1.1節，“MySQL郵件列表”](# "1.7.1.1.?The MySQL Mailing Lists")。請根據你使用的MySQL版本對所有缺陷報告或問題使用**mysqlbug**腳本！ 在Windows MySQL發布包里，mysqld.exe默認編譯為支持追蹤文件。 ### E.1.2.?創建跟蹤文件 如果**mysqld** 服務器沒有啟動或者你可以快速地使其崩潰，你可以創建一個跟蹤文件來找出問題。 要這么做的話，你必須有一個編譯了支持調試的**mysqld**，**** 你可以通過執行mysqld -V來檢查一下。如果版本號后面跟著-debug，它就是被編譯成支持跟蹤文件。（在 Windows中，調試服務器被命名為**mysqld-debug** 而不是象MySQL 4.1 那樣的**mysqld** ）。 如下命令，啟動帶跟蹤文件的 **mysqld** 服務器，跟蹤文件位于Unix上的/tmp/mysqld.trace目錄里，Windows上 的C:\mysqld.trace目錄里： ~~~ shell> mysqld --debug ~~~ 在Windows上，你也可以使用--standalone參數，啟動**mysqld**讓它不作為服務。在控制臺窗口，使用這個命令： ~~~ C:\> mysqld-debug --debug --standalone ~~~ 完畢之后，你可以使用第二個窗口中的 mysql.exe 命令行工具重新制造問題。你可以用**mysqladmin shutdown**命令停止**mysqld**服務器。 注意，跟蹤文件會變得**很大**！如果你想生成一個小一點的跟蹤文件，你可以使用類似這樣的調制選項： **mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace** 這樣就僅把帶最感興趣標記的信息寫進跟蹤文件里. 如果你生成一個有關于此的缺陷報告，請只用把跟蹤文件中的相關行發送到恰當的郵件列表去，那里關注你報告出問題的部分。如果你不能找出哪里出問題，你可以ftp上載整個跟蹤文件到[ftp://ftp.mysql.com/pub/mysql/upload/](#)，并附有完全的缺陷報告，MySQL開發人員會看到它的。 追蹤文件是由Fred Fish用**DBUG**軟件包生成的，請參閱[E.3節，“DBUG軟件包”](# "E.3.?The DBUG Package")。 ### E.1.3.?在**gdb**環境下調試**mysqld** 如果**mysqld**崩潰了，在大多數系統上，你也可是從**gdb**啟動**mysqld**來獲取更多信息。 Linux上，有一些老版本的**gdb**，如果你想要能調試**mysqld**線程，你必須使用run --one-threadsome。在這種情況下，你可以一次只激活一個線程。我們推薦你升級到gdb 5.1 ASAP ，這個版本上線程調試工作得更好！ NTPL 線程（Linux上的新線程庫）可能會在**gdb**下運行**mysqld**時遇到問題。一些癥狀如下： - **mysqld** 在啟動過程中掛起（在它寫ready for connections之前）。 - **mysqld** 在調用pthread_mutex_lock()或pthread_mutex_unlock()過程中崩潰。 在這種情況下你應該在啟動**gdb**之前在外殼上設置如下環境變量： ~~~ LD_ASSUME_KERNEL=2.4.1 export LD_ASSUME_KERNEL ~~~ 在**gdb**下運行**mysqld**時，你應該用--skip-stack-trace來禁止堆棧跟蹤，以便能捕獲**gdb**內的段錯誤。 在MySQL 4.0.14和以上版本，你應該對mysqld使用--gdb選項。 這會為SIGINT安裝一個中斷處理器（需要用^C停止**mysqld**來設置斷點），并且禁止堆棧跟蹤和核心文件處理。 當**gdb**沒有給舊線程釋放內存的整個時間里，如果你做了大量的新連接，在**gdb**下調試MySQL是非常困難的。你可以通過帶 -O thread_cache_size= 'max_connections +1' 啟動**mysqld** 來避免這個問題。在多數情況下，只使用-O thread_cache_size=5'就受益無窮了！ 如果**mysqld**帶著SIGSEGV信號死掉了，而你想在Linux上轉儲核心，你可以帶--core-file選項啟動**mysqld**。這個核心文件可以被用來生成 向后跟蹤，它可以幫你找出**mysqld** 為何死掉： ~~~ shell> gdb mysqld core gdb> backtrace full gdb> exit ~~~ 請參閱[A.4.2節，“如果MySQL依舊崩潰，該如何去做”](# "A.4.2.?What to Do If MySQL Keeps Crashing")。 如果你在Linux上使用**gdb** 4.17.x 或以上版本，你應該安裝一個帶有如下信息的 .gdb 文件到你當前目錄： ~~~ 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**調試線程遇到問題，你應該下載gdb 5.x版本并用它試一下調試。新版本的 **gdb** 大大改善了線程處理！ 下面是如何調試mysqld的例子： ~~~ shell> gdb /usr/local/libexec/mysqld gdb> run ... backtrace full # Do this when mysqld crashes ~~~ 把上面的輸入寫進一個用**mysqlbug**生成的郵件里，發送到綜合MySQL郵件列表。請參閱[1.7.1.1節，“MySQL 郵件列表”](# "1.7.1.1.?The MySQL Mailing Lists")。 如果**mysqld** 掛起，你可以試著用一些諸如strace 或 /usr/proc/bin/pstack 這樣的系統工具連檢查**mysqld** 在哪里掛起。 ~~~ strace /tmp/log libexec/mysqld ~~~ 如果你使用 Perl DBI 接口，你可以使用trace方法或設置DBI_TRACE環境變量來打開調試信息。 ### E.1.4.?使用堆棧跟蹤 在一些操作系統上，如果**mysqld**意外死掉，錯誤日志包含一個堆棧跟蹤。你可以用它來找出**mysqld** 在哪里（也許可能找出為什么）死掉。請參閱[5.11.1節，“錯誤日志”](# "5.11.1.?The Error Log")。要獲得堆棧跟蹤，你不能用-fomit-frame-pointer 選項編譯**mysqld** 為gcc。 請參閱[E.1.1節，“針對調試編譯MySQL”](# "E.1.1.?Compiling MySQL for Debugging")。 如果錯誤文件包含類似下面的一些內容： ~~~ 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**在什么地方出現問題： 1. 復制前面的數字到一個文件，如mysqld.stack。 1. 為 **mysqld** 服務器生成符號文件： ~~~ nm -n libexec/mysqld > /tmp/mysqld.sym ~~~ 注意，多數MySQL二進制發布包（"debug" 軟件包，包含這些信息的地方就在二進制發布包本身之內）帶上述文件，在其中這些文件名為mysqld.sym.gz。在這種情況下，你可以簡單地解壓縮它： ~~~ gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym ~~~ 1. 執行 resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack. 這個命令會打印出**mysqld**死在哪里。如果這個不能幫你找出**mysqld**為什么死掉，你應該生成一個缺陷報告，并在缺陷報告里包含上述命令的輸出結果。 注意，盡管在多數情況下，僅有一個堆棧跟蹤不能幫助我們找出問題的原因。為了定位缺陷或找到一個大致范圍，我們在大多數情況下需要知道殺掉**mysqld**的查詢，并最好知道一個測試案例 ，以便我們能重復問題！請參閱[1.7.1.3節，“如何報告缺陷和問題”](# "1.7.1.3.?How to Report Bugs or Problems")。 ### E.1.5.?使用日志文件找出**mysqld中**的錯誤原因 注意，在帶--log選項啟動 **mysqld**之前，你應該用**myisamchk**檢查所有的表。請參閱[第5章：*數據庫管理*](# "Chapter?5.?Database Administration"). 如果 **mysqld** 死了或掛起，你應該用--log啟動 **mysqld** 。當**mysqld** 再次死掉時，你可以檢查日志文件的最后，找出殺掉**mysqld**的查詢。 如果你不帶文件名使用 --log ，日志被保存在*名為host_name*.log的數據庫目錄里。在多數情況下，日志文件中的最后一個查詢殺掉**mysqld**，但如果有可能，你應該重啟**mysqld**并從**mysq**命令行工具執行找到的查詢來驗證一下。如果這個查詢殺掉**了mysqld**，你也應該測試所有沒有完成的復雜查詢。 你也可以在所有占用長時間的SELECT聲明上用命令EXPLAIN來確認 **mysqld**正適當地使用索引。請參閱[7.2.1節，“EXPLAIN 語法（獲得關于SELECT的信息）”](# "7.2.1.?EXPLAIN Syntax (Get Information About a SELECT)")。 你可以帶 --log-slow-queries啟動**mysqld**來找出占用長時間來執行的查詢。請參閱[5.11.4節 ，“緩慢查詢日志”](# "5.11.4.?The Slow Query Log")。 如果你在錯誤日志文件（通常名為hostname.err）中發現 mysqld restarted 字樣，你大致已經找到導致**mysqld**的查詢。如果發生這種情況，你應該用**myisamchk**檢查所有表（參閱 [ 第5章：*數據庫管理*](# "Chapter?5.?Database Administration")），并在MySQL日志文件中測試這些查詢看是否有不執行的。如果找到這樣一個查詢，試著升級到最新的MySQL版本。如果這樣不能幫助你，你不能在mysql郵件存檔中發現任何相關內容，你應該把缺陷報告給MySQL郵件列表。郵件列表在[http://lists.mysql.com/](http://lists.mysql.com/)訂閱，這個地址上也有連到在線列表存檔的鏈接。 如果你已經用myisam-recover啟動了**mysqld**，MySQL自動檢查并試著修復MyISAM 表，看是否它們被標志為“未正常關閉”或“崩潰”。如果發生這種情況，MySQL在文件hostname.err 寫一個條目'Warning: Checking table ...'，后面跟著警告：如果表需要修復，請修復它。如果你遇上大量的這些錯誤而**mysqld**沒有意外死掉，那就是有問題了，需要進一步調查。請參閱[5.3.1節，“**mysqld**命令行選項”](# "5.3.1.?mysqld Command-Line Options")。 如果**mysqld**意外死掉，這可不是一個好兆頭，但在這種情況下不用研究Checking table...信息，而是要找出**mysqld**為什么死掉。 ### E.1.6.?如果出現表崩潰，請生成測試案例 如果在一些更新命令之后，**mysqld**總是當掉，或者如果你遇到被破壞的表，你可以用下面的操作測試看這個缺陷是否是可重復產生的： - 卸掉MySQL守護進程（用**mysqladmin shutdown**）。 - 給該表做備份（防止修復操作反而搞壞這種很不可能出現的情況）。 - 用 **myisamchk -s database/*.MYI** 檢查所有的表，用**myisamchk -r database/*table*.MYI**修理有錯誤的表。 - 對該表做第二次備份。 - 如果需要更多的空間就從MySQL數據庫目錄刪除（或移走）舊日志文件。 - 帶--log-bin啟動Start **mysqld** 。請參閱[5.11.3節，“二進制日志”](# "5.11.3.?The Binary Log")。如果你想找出搞垮**mysqld**的查詢，你應該使用use --log --log-bin。 - 當你已經遭遇一個被破壞的表時，請停止mysqld server 。 - 還原備份。 - 不帶--log-bin重啟動**mysqld** 服務器。? - 重新執行**mysqlbinlog update-log-file | mysql**命令。更新的日志用名字hostname-bin.#保存在MySQL數據庫目錄下。 - 如果該表再次被破壞，或者你可用上訴命令讓**mysqld** 死掉，你就已經找到可重復產生的缺陷，它應該很容易被修復！可以ftp上傳表和二進制日志到 [ftp://ftp.mysql.com/pub/mysql/upload/](#) 然后把它輸入我們在 [http://bugs.mysql.com/](http://bugs.mysql.com/)上的缺陷系統。（請注意，/pub/mysql/upload/ 在FTP時是不可以列出（內容）的，所以不能在FTP客戶端看見你已經上載的東西。）如果你是一個支持客戶，你可以使用 MySQL客戶支持中心[https://support.mysql.com/](https://support.mysql.com/) 來 提醒MySQL 技術人員這個問題，讓這個問題盡快得到解決。 如果你想縮小問題的范圍，你也可以使用 mysql_find_rows腳本來只執行一些 更新語句。 ### E.2.?調試MySQL客戶端 為能夠用集成的調試軟件包調試MySQL客戶端 ，你應該用--with-debug或--with-debug=full配置MySQL。請參閱[2.8.2節，“典型的配置選項”](# "2.8.2.?Typical configure Options")。 在運行客戶端之前，你應該設置 MYSQL_DEBUG環境變量： ~~~ shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace shell> export MYSQL_DEBUG ~~~ 這會導致客戶端在 /tmp/client.trace目錄產生一個跟蹤文件。 如果你自己的客戶端代碼有問題，你應該試著連接到服務器，用已知可用的客戶端運行你的查詢。在調試模式下，按下面命令運行（假設你已經帶調試編譯了MySQL）： ~~~ shell> mysql --debug=d:t:O,/tmp/client.trace ~~~ 萬一你要發送一個缺陷報告郵件，這會提供給你有用的信息。請查閱[“如何報告缺陷或問題”](# "1.7.1.3.?How to Report Bugs or Problems")。 如果你的客戶端在一些看起來合法的代碼處崩潰了，你應該檢查你的mysql.h文件是否包括匹配你的MySQL庫文件。一個常見的錯誤就是用新的版本的MySQL庫使用一個來自老版本安裝的mysql.h文件。 ### E.3.?DBUG軟件包 MySQL服務器和多數MySQL客戶端都帶著由Fred Fish初創的DBUG 軟件包編譯成的。當你為調試配置MytSQL之時，這個軟件使你可以得到一個程序正在調試什么的跟蹤文件。請參閱[E.1.2節，“創建跟蹤文件”](# "E.1.2.?Creating Trace Files")。 這一節總結了你對已建立支持調試的MySQL程序在命令行的調試選項處可以指定的參量值。要獲取更多使用DBUG軟件包來編程的信息，請參閱MySQL源發布包里dbug目錄下的DBUG手冊。最好使用最近的MySQL 5.1發布包以獲得最近更新的DBUG手冊。 你通過用--debug="..."或the -#... 選項調用一個程序來使用調試軟件包。 多數MySQL程序有默認的調試字符串，如果你不給--debug指定一個選項，就使用這個默認的。默認的跟蹤文件通常是/tmp/program_name.trace（在Unix上）和\program_name.trace （在Windows上）。 調試字符串是一系列冒號隔開的區段，如下： ~~~ <field_1>:<field_2>:...:<field_N> ~~~ 每個區段包含一個強制標志字符，后面跟著已和可選的 ‘,’ 以及一列用逗號隔開的修改量： ~~~ flag[,modifier,modifier,...,modifier] ~~~ 當前被識別的標記符號是： | ** 標記** | **描述** | |-----|-----| | d | 允許對當前狀態從DBUG_<N>宏輸出。可能跟著一列關鍵詞，這些關鍵詞僅對那些帶有關鍵詞的DBUG宏選擇輸出。一個空的關鍵詞列意味著對所有宏輸出。 | | D | 在每個調試起輸出行后延遲。參量一個十分之一秒為單位來延遲的數，它受限于機器的能力。比如 -#D,20 指定一個2秒的延遲。 | | f | 限制調試和/或跟蹤，以及簡單設定于列出名字的函數。注意，空列將禁止所用函數。應該給出適當的d 或 t 標記，如果它們被允許了，這個標記僅限制它們的動作。 | | F | 對調試或跟蹤輸出的每一行識別源文件名。 | | i | 對調試或跟蹤輸出的每一行用PID或線程ID識別進程。 | | g | 允許解析，創建名為的dbugmon.out文件，它包含可用來簡單設定程序的信息。可能跟著一列關鍵詞，它們是選擇只對列中的函數做簡單設定。一個空列意味著所有函數都要考慮到。 | | L | 為調試或跟蹤輸出的每一行識別源文件行號。 | | n | 為調試或跟蹤輸出的每一行打印當前函數嵌套深度。 | | N | 給調試輸出的每一行編號。 | | o | 重定向調試器輸出流到指定文件。默認輸出是stderr 文件。 | | O | 類似于 o，但是文件在每次寫操作之間被沖刷。當需要之時，文件在每次寫操作之間被關閉然后重新打開。 | | p | 限制調試器作用于指定進程。為使調試器動作，一個進程必須用DBUG_PROCESS宏來識別，且匹配列表中的一個。 | | P | 為調試或跟蹤輸出的每一行打印當前進程名字。 | | r | 當推出一個新狀態時，不繼承前狀態的操作嵌套深度級別。當輸出在左邊空白開始時有用。 | | S | 在每個調試過的函數做_sanity(_file_,_line_)函數直到 _sanity() 返回不同于0的結果。（大多數的時候與safemalloc 一起用來找出內存漏洞）。 | | t | 允許函數調用/退出跟蹤行。可能跟著一個給出最大跟蹤級別的數字列（只含一個修改量），超過這個數字，調試中或跟蹤中的宏不能產生任何輸出。 默認為一個編譯時間選項。 | 可能出現在外殼命令行（-# 典型地被用來引入一個控制字符串到一個應用程序中） 的調試控制字符串的一些例子如下： ~~~ -#d:t -#d:f,main,subr1:F:L:t,20 -#d,input,output,files:n -#d:t:i:O,\\mysqld.trace ~~~ 在MySQL中, 打印的一般標記是（用 d 選項）是 enter, exit, error, warning, info, 和 loop 。 ### E.4.?關于RTS線程的注釋 我曾嘗試讓MySQL使用RTS線程軟件包，但是在下面的問題上遇到阻礙： RTS線程軟件包很多老版本的POSIX調用，對所有函數的寫封裝就很枯燥。我傾向于認為把線程庫換成最新的POSIX規格，會更容易些。。 一些封裝正在編寫中。更多信息請參閱mysys/my_pthread.c 文件。 至少下面說道的應該改變一下： pthread_get_specific該使用一個參量。 sigwait應該使用兩個參量。很多函數（至少pthread_cond_wait, pthread_cond_timedwait()）應該返回錯誤的錯誤代碼。現在它們返回 -1 且設置 errno。 另一個問題是，用戶級線程使用ALRM信號，這會終止很多函數（read, write, open...）。MySQL應該重試一下所有這上面的中斷，但是這并非很容易去驗證。 最大的未解決問題如下： 要獲得線程級警報，我使用pthread_cond_timedwait()改變 mysys/thr_alarm.c，讓它在警報之間等待。但是它發生EINTR錯誤，終止了。我試著調試線程庫找出為什么會出這個錯誤，但是找不到一個簡便 的解決辦法。 如果人人想要用RTS線程跑一下MySQL，我建議以下幾點： - 把MySQL使用的函數從線程庫變到POSIX。這不會占據那么長時間。 - 用-DHAVE_rts_threads編譯所有庫。 - 編譯thr_alarm。 - 若在執行中有一些小的差異，可以改變my_pthread.h和my_pthread.c來修復它們。 - 運行thr_alarm。如果它沒有任何警告，錯誤或終止信息地運行，你就做對了。這里是一個在Solaris成功運行的例子： ~~~ 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 ~~~ ### E.5.?線程軟件包之間的差異 MySQL非常依賴使用中的線程軟件包。 所以當為MySQL選擇一個好平臺的時候，線程軟件包就非常重要。 至少有三種線程軟件包： - 用戶線程在單個進程中。線程切換用警報管理，線程庫用鎖管理所有非線程安全函數。讀，寫和選擇操作通常被線程專有的切換器管理， 如果運行中的線程要等待數據，這個切換器就會切換操作到另一個線程。如果用戶線程軟件包集成在標準庫（FreeBSD 和 BSDI 線程軟件包）里，這樣的 線程軟件包比那些不得不映射所有不安全調用（MIT-pthreads, FSU Pthreads 和 RTS 線程軟件包）的線程軟件包需要更少的系統開銷。在某些環境下（如SCO），所有系統調用都是線程安全的，所以映射非常容易（SCO上的FSU Pthreads包）。不足之處是：所有映射的調用占用很少的時間，于是想要能處理所有的情況就相當繁雜。有一些系統調用通常不被線程軟件包（類似MIT-pthreads and sockets包）處理。線程計劃不總是最優化的。 - 在分離進程中的用戶線程。線程切換是由內核來做，且所有的數據在線程之間共享。線程軟件包管理標準線程調用，允許在線程之間共享數據。LinuxThreads包就使用這種方法。不足之處：太多進程。線程創建得慢，如果一個線程死掉了，其余得線程通常就掛起來，你必須在重啟之前殺掉這些掛起的線程。線程切換開銷有些大。 - 內核線程。線程切換由線程庫或內核來做，并且非常快。一個進程就可以了。但在一些系統中**ps**可能顯示不同線程。如果一個線程終止，整個進程就終止了。多數系統 調用是線程安全的，并且只要非常小的系統開銷。Solaris, HP-UX, AIX 和OSF/1 都有內核線程。 在一些系統中內核線程被系統庫中整合用戶級線程管理。在這種情況下，線程切換只能由線程庫來做，而內核并不是真正的“線程感知”的。 這是MySQL參考手冊的翻譯版本，關于MySQL參考手冊，請訪問[dev.mysql.com](http://dev.mysql.com/doc/mysql/en)。 原始參考手冊為英文版，與英文版參考手冊相比，本翻譯版可能不是最新的。