MySQL作为主流的关系型数据库，不同存储引擎的数据恢复逻辑存在明显差异，MyISAM和InnoDB是日常使用中最常见的两种引擎，对应的恢复手段也各有特点。
MyISAM存储引擎拷贝文件恢复方法
MyISAM引擎的表数据、索引、表结构分别存储在三个文件中，只要文件没有严重损坏，就可以通过拷贝文件的方式完成恢复，操作前需要先停止MySQL服务，避免文件被占用导致拷贝不完整。
MyISAM相关文件说明
| 文件后缀 | 文件作用 |
|---|---|
| .frm | 存储表的结构定义信息 |
| .MYD | 存储表的实际数据内容 |
| .MYI | 存储表的索引信息 |
具体操作步骤
- 停止目标MySQL服务，执行命令：systemctl stop mysqld 或者 service mysql stop
- 找到原数据库的存储目录，默认路径为 /var/lib/mysql/数据库名/，拷贝对应表的三个文件到新环境的同路径下
- 修改拷贝后文件的属主和权限，执行命令：chown -R mysql:mysql /var/lib/mysql/数据库名/，chmod 660 对应文件
- 启动MySQL服务，登录数据库验证表数据是否正常
需要注意，拷贝文件的MySQL版本、操作系统位数、字符集配置必须和原环境一致，否则可能出现表无法识别的问题。
InnoDB存储引擎日志恢复方法
InnoDB支持事务和崩溃恢复，依靠重做日志（redo log）和回滚日志（undo log）保证数据一致性，当数据库异常崩溃后，重启时会自动执行日志恢复，手动恢复则需要结合日志文件操作。
自动日志恢复机制
InnoDB在每次事务提交时，会把修改操作先写入redo log，再异步刷入磁盘数据页。如果数据库异常宕机，重启后会读取redo log中未刷盘的记录，重新执行这些操作，保证已提交事务的数据不丢失。这个过程是InnoDB自动完成的，不需要人工干预。
手动日志恢复场景与操作
当redo log文件损坏或者需要恢复到某个时间点的数据时，需要手动处理日志，操作前一定要先备份所有数据文件和日志文件，避免操作失误导致数据彻底丢失。
首先查看MySQL配置文件中的日志相关参数，执行以下命令查看配置：
-- 查看InnoDB日志文件配置 SHOW VARIABLES LIKE 'innodb_log_file_size'; SHOW VARIABLES LIKE 'innodb_log_files_in_group'; SHOW VARIABLES LIKE 'innodb_log_group_home_dir';
如果需要从备份的日志中恢复数据，可以使用mysqlbinlog工具解析二进制日志，再导入到数据库中，示例代码如下：
# 解析二进制日志为SQL文件 mysqlbinlog /var/lib/mysql/binlog.000001 > recovery.sql # 将解析后的SQL导入到目标数据库 mysql -u root -p 数据库名 < recovery.sql
如果是redo log损坏导致数据库无法启动，可以尝试在配置文件中添加innodb_force_recovery参数，参数值从1到6递增，数值越大恢复力度越强，但也可能造成部分数据丢失，启动后尽快导出数据重新搭建实例。
两种恢复方式的注意事项
- 无论使用哪种恢复方式，操作前都要对现有数据文件、日志文件做完整备份，避免二次损坏
- MyISAM拷贝文件恢复仅适用于表文件未损坏的场景，如果文件本身有坏块，需要结合
myisamchk工具先修复文件 - InnoDB手动恢复日志时，要确认日志的时间范围，避免导入无关的操作记录
- 生产环境操作前最好在测试环境先验证恢复流程，确认无误再在正式环境执行
数据恢复的核心是尽可能保留完整的数据文件和操作日志，日常运维中要做好定期全量备份和增量日志备份，出现问题时才能有更多恢复选择。