问题
我的 MySQL 偶尔崩溃，如果需要追查原因，应该如何保留现场？
实验
MySQL 随着版本不停迭代，崩溃的现象越来越少，也越来越隐蔽。
一旦遇到生产环境上的 MySQL 崩溃，就需要保留现场信息，供分析用。虽然 MySQL 的 error log 中会打印部分信息，但对于比较隐蔽的崩溃，往往显得力不从心。
因此我推荐开启 coredump，以备 MySQL 诊断需要。
我们来模拟一个崩溃场景，然后配置 coredump 看看效果。
选取一个容易复现崩溃的 bug，我们选择了 bug #95294。
我们先安装一个 5.7 的数据库，
将其停掉，按照 bug #95294 的描述变更配置，
手工启动 mysqld，可以看到 mysqld 无声无息的退出了，
检查 error log，可以看到 MySQL 是因为异常崩溃了，
error log 中有一段堆栈信息，可以用来判断这个崩溃的问题，
以上是 MySQL 能提供的所有信息，无法针对一些复杂场景进行分析。
下面我们开启 coredump，让 MySQL 在崩溃时能提供更多信息：
以下命令开启了系统级别一些参数，具体的释义大家可自行谷歌。此处需要注意，我们将 core 文件生成到了 /tmp 目录下，需要保证其磁盘空间足够大：
我们还需要调整 MySQL 运行用户的 ulimit，在本文中，MySQL 的运行用户是 root，我们调整其 core file 的限制，使其能生成 core dump：
最后，我们要在 MySQL 配置里，允许 MySQL 生成 coredump：
现在我们可以再次运行 MySQL：
可以看到 MySQL 崩溃时，会告知已生成了 core dump 文件。在 error log 中也会有同样的信息：
我们来看一下这个 coredump 文件：
coredump 文件会将崩溃当时的内存情况全部保留下来，所以文件体积会比较大。
小贴士：
在 MySQL 8.0.14 后，MySQL 提供了参数 innodb_buffer_pool_in_core_file，用于将 innodb buffer pool 从 coredump 中排除，用于减小 coredump 的体积。
那我们怎么使用 coredump 文件呢？可以用 gdb 去访问 coredump 文件，获取各种信息，此处举例如何获取所有线程的堆栈信息。
我们会得到一个非常长的堆栈信息，我们截取其中一小段，标注上简单的中文即可看懂。
结论
通过开启操作系统级别、放开用户限制、启用 MySQL 参数三个步骤，我们启用了 MySQL 的 coredump 功能，使得 MySQL 崩溃时留下了足够的线索。
对于复杂崩溃的分析，还是需要将 coredump 交给专业的研发工程师手里，或者提交给 MySQL 开发团队。
不过不管是什么场景，能提供一份 coredump，所有技术人员都会感谢你的。
关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
