突然断电，重启后导致个人电脑中的wordpress数据库受损；
此数据是在本地经过很长一段时间的录入、维护的，而且在本地从末因断电或其他原因导致的数据损坏，故没有备份。所以很心塞！
故障从wamp（wamp server 2.5）服务无法正常启动开始，查apache错误日志和mysql日志以及计算机事务日志，找到关键提示：
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
2016-08-19 09:26:26 5488 [Note] Plugin ‘FEDERATED’ is disabled.
原因是mysql发生crash错误导致无法恢复而引起的wamp启动失败！
随即按提示，修改my.ini文件(位于wamp\bin\mysql\mysql5.6.17目录下)，添加：
innodb_force_recovery = 1;
重启服务，wamp顺利启动。
随后打开phpmyadmin时发现，表不见了！！！而实际data目录下，文件是存在的。
查mysql日志提示：
2016-08-19 09:43:21 5148 [ERROR] InnoDB: Table wpdb/wp_commentmeta in the InnoDB data dictionary has tablespace id 85, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
至此，问题原因找到，参考日志提供的链接，得解决过程如下：
一、原因说明
根据日志提示，当前错误原因是因为数据库各表的tablespace(表空间）丢失而引起的数据读取错误。而实际数据文件.ibd文件并没有丢失；
在该前提下，可通过重建表结构，并导入.ibd文件进行有效恢复。
二、依赖的关键命令
ALTER TABLE wp_options DISCARD TABLESPACE; 丢弃表空间
ALTER TABLE wp_options IMPORT TABLESPACE; 导入表空间
三、重构表结构
新建个数据库，比如wp_demo，利用wordpress的自安装程序，进行数据表结构重建。
四、导入.idb进行恢复
如果您不熟悉mysql命令，以下过程建议在phpmyadmin中进行。
由于wordpress的数据表不是太多，所以逐一进行恢复，这里以wp_options表为例执行
1、 打开phpmyadmin,选择wp_demo,并打开sql命令窗口
2、执行 ALTER TABLE wp_options DISCARD TABLESPACE;命令
3、打开wp_demo数据库所在data目录，比如：wamp\bin\mysql\mysql5.6.17\data\wp_demo
4、将原损坏数据库下的wp_options.ibd文件拷贝到wp_demo文件夹下
5、执行 ALTER TABLE wp_options IMPORT TABLESPACE;命令
6、执行完成后，查看wp_options表是否已恢复正常。
如一旦恢复成功，先导出备份！
以上步骤本人亲测成功，百度了一大把的资料，唯有官方的链接最靠谱；
如果还有不明白的，建议稳步至http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html进行细致研究。
注1：数据要做好备份！数据要做好备份！数据要做好备份！重要的事说三遍！
注2： 关于innodb_force_recovery的解释
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0，表示当需要恢复时执行所有的恢复操作。当不能进行有效的恢复操作时，mysql有可能无法启动，并记录下错误日志。
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):不执行前滚的操作。
原文参考：http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html