MySQL数据库INNODB 表损坏修复处理过程

最近mysql数据库经常死掉，用命令net stop mysql命令也无法停掉，关闭Tomcat的时候，出现Waiting for N instance(s) to be deallocated 信息。查了下，大概就是程序没有对数据库连接释放，导致Connection泄露了。因为用的是开元集成的平台，内部程序也不可能一下子给改掉的，就验证一下咯。启动Tomcat,用户登录系统，用netstat -ano|findstr 8000命令来查看tomcat端口占用情况，可以看到8000端口会被用户的IP地址占用，而对应的PID是0，PID=0是什么呢，是叫System Idel Process的一个进程，这个进程是一个空闲的进程。Tomcat一直被这个进程占用，没有释放，时间长了用户多了，mysql就死掉了，至于是不是程序没有释放连接，这个应该是没可能，因为系统已经用了2年，这种情况出现的太少了。
看一下mysql中表的情况，表的数据长度到达了几个G了，这种是BLOB类型的，存储的数据过多，这样的话是不是因为数据量太大，用户在用的时候对数据库进行操作，空间又不够，互相等待，造成死锁的问题呢？
这年头，一定要注意备份啊，mysql要备份的东西比较多，
(1)表结构文件，MySQL\MySQL Server 5.1\data目录下存放的就是数据库结构，会看到相应的数据库目录，数据库目录下面有.frm文件,.myd文件，.myi文件，这些文件都是表结构的文件。
(2)表数据文件，MySQL Datafiles/ibdata1文件
(3)日志文件，MySQL\MySQL Server 5.1\data目录下面ib_logfile0文件和ib_logfile1文件。二进制日志文件，如果你想要重新处理日志止的语句，这很有用。
你的数据库结构没有问题的情况下，想恢复数据，如果有（2）、（3）应该是没有问题的，当时我只有（2），把ibdata1文件copy过去，恢复数据还是出了很多状况，启动系统还是不能用的，mysql日志一直提示Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files.说多了都是泪，谁让咱是IT呢，系统坏掉了电话都要被用户打爆的节奏，hold不住，无所不用其极的，各种搜索资料啊，最后尝试一下大多数人的办法，设置innodb_force_recovery参数。
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0，表示当需要恢复时执行所有的

innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。

1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
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):不执行前滚的操作。
设置innodb_force_recovery=4重启msql,再恢复成默认值（即不需要再my.ini文件时设置innodb_force_recovery参数），重启mysql，重启Tomcat，OK了，太惊喜了。
菜鸟一个，其中原理讲的都不太清楚，经验之谈，仅供参考。