MySQL损坏数据恢复

    mysql>CREATE DATABASE sakila

    mysql>USE sakila

    mysql>CREATE TABLE actor (

        actor_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,

        first_name VARCHAR(45) NOT NULL,

        last_name VARCHAR(45) NOT NULL,

        last_update TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

        PRIMARY KEY  (actor_id),

        KEY idx_actor_last_name (last_name)

      )ENGINE=InnoDB DEFAULT CHARSET=utf8

    ALTER TABLE {库名}.{表名} DISCARD TABLESPACE

    例:

    mysql>ALTER TABLE sakila.actor DISCARD TABLESPACE

    cp /backup_directory/actor.ibd path/to/mysql-5.7/data/sakila/

    ALTER TABLE {库名}.{表名} IMPORT TABLESPACESHOW WARNINGS

    例:

    mysql>ALTER TABLE sakila.actor IMPORT TABLESPACESHOW WARNINGS

    Query OK, 0 rows affected, 1 warning (0.15 sec)

    Warning | 1810 | InnoDB: IO Read error: (2, No such file or directory)

    Error opening './sakila/actor.cfg', will attempt to import

    without schema verification

    mysql>SELECT COUNT(*) FROM sakila.actor

    +----------+

    | count(*) |

    +----------+

    |      200 |

    +----------+

在解决的过程中，以下几种尝试：1.如果开启了日志，直接mysqlbinlog 使用日志恢复即可。2.如果不是删除了一个表的部分数据，而是删除整个表，那么可以在删除后马上用磁盘数据恢复软件尝试恢复。（因为删除表后会有文件被删除，而删除表的部分数据，文件还是存在）3.找数据恢复的公司，使用工具分析ibdata1（分析过程参考一页一页查看有没有历史记录存在，使用ibdata1恢复数据，应该是在了解数据表结构的前提下，数据库除ibdata1外其他数据受损不能正常使用数据库时尝试，而不是删了表数据后恢复什么的。（事实上，这个文件是存储现有表数据的，其实也可以设置成每个表一个文件。）4.mysql下有ib_logfile0和ib_logfile1两个文件，其实这两个文件里，记录了Mysql的一些事物日志，用于事务的前滚后滚，是Mysql自身使用的，这个文件用文本工具打开后，有很多乱码，但却可以查找到被删除的少量数据的insert记录，极少数的乱码通过前后语句找出了原文，最终通过事物日志恢复了删除的文件。注：用事物日志恢复，需要几个前提。1：知道被删除数据的大概位置，不要这边查找，那边又不断有新数据插入。2：因为有很多乱码，适用于查找少量数据，而不是用作大量数据的恢复，浪费体力。3：如果二进制日志没开，没有备份，那么只能用这种方法恢复了。

---