基本思路是打出堆栈来分析
此时首先怀疑mysql内部发生了死锁
1. 使用pstack打出堆栈，会有一定性能影响
yum install gdb pstack mysql_pid > /tmp/pstack.out
也可以用gdb
gdb -batch -ex "thread apply all bt" -p mysql_pid > /tmp/gdb.log
堆栈可能比较多，需要耐心一点点排查，找出死锁的调用路径
2. 使用strace打出一段时间内的系统调用信息，会有一定性能影响
strace -o /tmp/strace_output.txt -T -tt -f -e trace=all -p {mysql_pid}
可以作为额外信息，辅助堆栈的排查
如果pstack或gdb也无法进入，那可能mysql已经不响应信号了
只能从操作系统提供的proc文件收集一些信息
cat /proc/mysql_pid/status
注意，status里除了进程状态之外，也有信号处理相关的信息Sig*
cat /proc/mysql_pid/task/*/stack
cat /proc/mysql_pid/syscall
cat /proc/mysql_pid/stack
当前的系统调用信息，比如是不是某个系统调用一直没有返回
ps -p{mysql_pid} -ocmd,stat,wchan
如果proc文件显示进程处于Running状态，没有夯在任何系统调用上
我目前能找到的方法就是打coredump，会杀死进程，但是能留下堆栈
prlimit --p $(mysql pid) --core=unlimited
先调整core limit，保证coredump文件能正常生成（linux 内核版本 2.6.36 以后才能使用prlimit）
kill -SIGSYS mysql_pid
linux有很多默认行为是打coredump的信号，但是有些信号被mysql捕获自己做了处理，比如SIGABRT，所以这里我们用SIGSYS
参考：http://man7.org/linux/man-pages/man7/signal.7.html
如果以上方法都没有成功收集到堆栈
那可能是操作系统层面的问题(或许可以从redhat bug文档中找类似问题)，或者是硬件问题，不简单是mysql bug导致的死锁
