背景描述
使用xa进行测试时，对mysql进行了一些xa各阶段锁定试验，后来出现卡死情况就杀掉了线程，重启了mysql服务。重启后发现插入、修改数据都正常，但无法修改表结构，修改表结构就处于卡死状态，过一分多钟报超时错误。多次重启mysql服务后,问题依然如故.
现象
查询innodb_trx表，发现有两个事务处于运行中。
SELECT * from information_schema.INNODB_TRX;
尝试解决
- 方案1--杀进程---行不通
网上资料都是说按照trx_mysql_thread_id找到对应进程杀掉，但我这里是0，没有进程id，没法杀，而且它是重启mysql服务后自动就运行的两个事务。这个方案的本质是要找到事务的发起者,然后通过发起者停掉事务，但我们这个问题中事务发起者未知。
2.方案2--xa rollback--不起作用
还有资料说，通过xarecover查看当前xa事务，然后回滚或提交。
我们根据xid进行事务的回滚或者提交，提示成功了。
xa ROLLBACK 'globalid','branch-2';
xa ROLLBACK 'globalid','branch-1';
我们在通过
xa recover查询发现确实没有xa事务了
是不是问题解决了呢？我们在看一下innodb_trx发现事务仍然存在，不能解决。
针对上面的xa rollback我们也可以尝试用xa commit，问题一样不能解决（需要再次重启mysql才能运行，否则会找不到对应的xid）。
xa COMMIT 'globalid','branch-2';
xa COMMIT 'globalid','branch-1';
问题分析
通过重启mysql后事务依然存在,我们大概推断应该跟redoundo有关系，xa事务异常后，mysql服务重启检测到了这两个事务就自动运行了，但因为未知原因，这两个事务并没有执行，一直处于running状态。
曾经试图研究mysql的redo undo机制或者对应的文件格式，但时间关系没有深入。
尝试能否打开对应的redo文件，对里面的语句进行修改，但网上找了资料没有合适的工具可以做这个事情。
一直很苦恼的思索解决办法，也咨询身边的一些朋友，对没有遇到过这方面的问题。
可行的解决方案
今天灵机一动，奔着大不了重新安装mysql的心态进行了破坏性的探索，当然前提要提前把数据备份出来。尝试停止mysql服务后，将mysql对应的datadir目录下几个文件删除掉，对应文件见下图。
然后重启mysql服务，曾担心启动失败的，但没想到mysql顺利的启动成功了，然后查看对应的表，发现一只running的事务终于消失了。
世界终于回归美好了，一片幸福感洋溢在温馨的大地上。
后续有时间我会继续深入分析其中的原理。
