有没有办法删除MySQL中具有待处理事务的InnoDB表或数据库（最好在文件系统级别）？
发生了什么：
我使用MySQL 5.5.28并运行LOAD DATA INFILE…将一个巨大的数据集（300M行）导入InnoDB表。我以前没用过set autocommit = 0;。不幸的是，mysqld在导入过程中被阻止了。
当我重新启动时mysql，它将尝试回滚使用以下消息填充系统日志的事务：
mysqld_safe [4433]：121212 16:58:52 InnoDB：等待1个活动事务完成
问题是回滚现在已经运行了25多个小时，在此期间 mysqld不接受任何套接字连接。
我不能只是删除/var/lib/mysql/*并从头开始，因为这台机器上还有其他一些InnoDB数据库/表。但是，有问题的表是单独数据库中的唯一表。删除整个表或整个数据库不是问题，因为之后我可以重新导入所有数据。
Answers:
您实际上无法做任何事情，因为正在通过ibdata1内部的UNDO表空间进行回滚，该回滚应该已经大大增加了。
如果您杀死mysqld进程并重新启动mysql，它将作为崩溃恢复周期的一部分从中断处恢复。
您可能会做的事可能会导致其他表的数据丢失，但是您可以采取一些措施来规避InnoDB的正常崩溃恢复周期。
有一个名为innodb_force_recovery的启动选项，它使您可以绕过InnoDB崩溃恢复的各个阶段。
根据有关强制InnoDB恢复的MySQL文档，以下是设置及其效果：
1（SRV_FORCE_IGNORE_CORRUPT）
即使服务器检测到损坏的页面，也要让服务器运行。尝试使SELECT * FROM tbl_name跳过损坏的索引记录和页，这有助于转储表。
2（SRV_FORCE_NO_BACKGROUND）
阻止主线程运行。如果在清除操作期间发生崩溃，则此恢复值可防止崩溃。
3（SRV_FORCE_NO_TRX_UNDO）
崩溃恢复后不要运行事务回滚。
4（SRV_FORCE_NO_IBUF_MERGE）
防止插入缓冲区合并操作。如果它们会导致崩溃，请不要这样做。不计算表统计信息。
5（SRV_FORCE_NO_UNDO_LOG_SCAN）
启动数据库时不要查看撤消日志：InnoDB甚至将未完成的事务都视为已提交。
6（SRV_FORCE_NO_LOG_REDO）
不要在恢复过程中进行重做日志前滚。
将事务更改埋在UNDO和REDO日志中，您将面临以下风险：
如果您预计会有不良的副作用，请备份整个/ var / lib / mysql并将其放在某个地方，以防您要复制ibdata1，ib_logfile0和ib_logfile1并重试正常恢复。
如果mysql在以下一种模式下完全启动
注意：请确保备份所有内容！！！
我希望这有帮助 ！！！
我这周也有类似情况。
在将完整备份还原到测试服务器并尝试使用巨大的未决事务删除，删除或杀死表的四次迭代之后，我们最终到了星期五下午，决定让它运行。在三天的时间里，事务以可忽略的服务器负载完成，数据库运行良好。这比对尝试过并失败的.frm文件和mysql表的任何手动操作要好得多。
我的解决办法：不要删除它。即使您不得不推迟几天的其他操作，或者在某处找到一些磁盘空间，或者让您的从属服务器承担负载，也要允许挂起的事务完成。