如果你遇到一些非常明确的问题，你可以总是试着调试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脚本来只执行一些 更新语句。