如果您遇到一些非常明確的問題，您可以總是試著調試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郵件列資料表」。請根據您使用的MySQL版本對所有問題報告或問題使用mysqlbug指令！

在Windows MySQL發佈包裡，mysqld.exe預設編譯為支援追蹤檔案。

如果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軟件包」。

如果mysqld崩潰了，在大多數系統上，您也可是從gdb啟動mysqld來獲取更多訊息。

Linux上，有一些老版本的gdb，如果您想要能調試mysqld線程，您必須使用run --one-threadsome。在這種情況下，您可以一次只激活一個線程。我們推薦您升級到gdb 5.1 ASAP ，這個版本上線程調試工作得更好！

NTPL 線程（Linux上的新線程庫）可能會在gdb下運行mysqld時遇到問題。一些症狀如下：

在這種情況下您應該在啟動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依舊崩潰，該如何去做」。

如果您在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 郵件列資料表」。

如果mysqld 掛起，您可以試著用一些諸如strace 或 /usr/proc/bin/pstack 這樣的系統工具連檢查mysqld 在哪裡掛起。

strace /tmp/log libexec/mysqld

如果您使用 Perl DBI 接口，您可以使用trace方法或設置DBI_TRACE環境變數來打開調試訊息。

在一些作業系統上，如果mysqld意外死掉，錯誤日誌包含一個堆棧跟蹤。您可以用它來找出mysqld 在哪裡（也授權能找出為什麼）死掉。請參閱5.11.1節，「錯誤日誌」。要獲得堆棧跟蹤，您不能用-fomit-frame-pointer 選項編譯mysqld 為gcc。 請參閱E.1.1節，「針對調試編譯MySQL」。

如果錯誤檔案包含類似下面的一些內容：

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在什麼地方出現問題：

注意，在帶--log選項啟動 mysqld之前，您應該用myisamchk檢查所有的資料表。請參閱第5章：資料庫管理.

如果 mysqld 死了或掛起，您應該用--log啟動 mysqld 。當mysqld 再次死掉時，您可以檢查日誌檔案的最後，找出殺掉mysqld的查詢。

如果您不帶檔案名使用 --log ，日誌被保存在名為host_name.log的資料庫目錄裡。在多數情況下，日誌檔案中的最後一個查詢殺掉mysqld，但如果有可能，您應該重啟mysqld並從mysq命令行工具執行找到的查詢來驗證一下。如果這個查詢殺掉了mysqld，您也應該測試所有沒有完成的複雜查詢。

您也可以在所有佔用長時間的SELECT聲明上用命令EXPLAIN來確認 mysqld正適當地使用索引。請參閱7.2.1節，「EXPLAIN 語法（獲得關於SELECT的訊息）」。

您可以帶 --log-slow-queries啟動mysqld來找出佔用長時間來執行的查詢。請參閱5.11.4節 ，「緩慢查詢日誌」。

如果您在錯誤日誌檔案（通常名為hostname.err）中發現 mysqld restarted 字樣，您大致已經找到導致mysqld的查詢。如果發生這種情況，您應該用myisamchk檢查所有資料表（參閱 第5章：資料庫管理），並在MySQL日誌檔案中測試這些查詢看是否有不執行的。如果找到這樣一個查詢，試著升級到最新的MySQL版本。如果這樣不能幫助您，您不能在mysql郵件存檔中發現任何相關內容，您應該把問題報告給MySQL郵件列資料表。郵件列資料表在http://lists.mysql.com/訂閱，這個地址上也有連到線上列資料表存檔的連結。

如果您已經用myisam-recover啟動了mysqld，MySQL自動檢查並試著修復MyISAM 資料表，看是否它們被標誌為「未正常關閉」或「崩潰」。如果發生這種情況，MySQL在檔案hostname.err 寫一個條目'Warning: Checking table ...'，後面跟著警告：如果資料表需要修復，請修復它。如果您遇上大量的這些錯誤而mysqld沒有意外死掉，那就是有問題了，需要進一步調查。請參閱5.3.1節，「mysqld命令行選項」。

如果mysqld意外死掉，這可不是一個好兆頭，但在這種情況下不用研究Checking table...訊息，而是要找出mysqld為什麼死掉。

如果在一些更新命令之後，mysqld總是當掉，或者如果您遇到被破壞的資料表，您可以用下面的操作測試看這個問題是否是可重複產生的：

如果您想縮小問題的範圍，您也可以使用 mysql_find_rows指令來只執行一些 更新語句。