MySQL 崩溃后能否恢复，取决于三件事：是否开启了
log_bin、InnoDB 表空间是否物理损坏、以及最近一次备份是否有效。只要 binlog 开启 + 有可用全量备份，95% 的崩溃场景（包括误删、断电、服务异常退出）都能完整恢复；若表空间已报
InnoDB: Database page corruption或
Tablespace has been discarded，则必须走
innodb_force_recovery分级抢救或从物理备份重建。
确认崩溃类型：看错误日志里有没有这三行关键提示
别急着重启，先查
/var/lib/mysql/hostname.err（或
mysqld.log）：
InnoDB: Database was not shut down normally→ 属于「软崩溃」，InnoDB 能自动重放 redo log，大概率启动即恢复
InnoDB: Database page corruption on disk或
page 5类似报错 → 「硬损坏」，磁盘/文件系统出问题，需强制恢复或换备份
Can't open shared memory segment或
Address already in use→ 非数据损坏，只是 mysqld 残留进程没清干净，
killall mysqld再试
如果日志里反复出现
srv_master_thread looped或
cannot allocate memory，说明不是崩溃而是 OOM 导致假死，应优先调大
innodb_buffer_pool_size并检查连接数。
能启动但数据不一致？立刻停写，用 innodb_force_recovery
分级导出
当 MySQL 能启动但查询报错（如
ERROR 2013 (HY000): Lost connection to MySQL server during query），说明部分页已损坏，但缓冲池还能加载部分数据 —— 这时不能直接 dump，得靠分级强制恢复抢出可用数据：
[mysqld] innodb_force_recovery = 1 innodb_purge_threads = 0
从
1开始试，每级只加 1，成功启动后立即执行：
mysqldump --single-transaction --routines --triggers --all-databases > full_backup.sql导出成功后，**立刻注释掉
innodb_force_recovery并重启服务**（该参数开启时禁止写入，且跳过崩溃恢复逻辑） 若
=1失败，再试
=3（跳过 undo 回滚）、
=6（跳过 redo 重放）——但注意：
=6会丢失未刷盘的事务，仅作最后手段
切记：
innodb_force_recovery不是修复命令，它只是“绕过检查强行读”，导出的数据可能缺行或字段为空，务必在测试库验证后再上线。
binlog 恢复必须满足两个前提，缺一不可
想用
mysqlbinlog做时间点恢复（PITR），光有
mysql-bin.0000xx文件远远不够： 前提 1： 启动时必须带
--server-id=非0值（哪怕单机也要设），否则 binlog 事件不记录
XID，崩溃恢复时无法关联 redo log 和 binlog 事务 前提 2： 全量备份必须是
mysqldump --master-data=2或
xtrabackup生成的，否则你不知道备份对应哪个 binlog 文件和 position
典型恢复链路：
mysql < full_backup.sql mysqlbinlog --start-position=12345 mysql-bin.000012 | mysql mysqlbinlog --stop-datetime="2025-12-29 14:22:00" mysql-bin.000013 | mysql
如果执行时报
ERROR 1062 (23000) at line XXX: Duplicate entry，说明 binlog 里有重复 DDL（如两次 CREATE TABLE），需加
--skip-gtids或手动过滤掉建表语句。
最常被忽略的致命细节：备份有效性验证必须离线做
很多团队备份脚本每天跑成功，但从未验证过备份文件能不能用。真实故障时才发现
backup.sql最后 10MB 是空的，或
mysql-bin.000123校验失败： 逻辑备份验证：
head -n 50 backup.sql | grep "CREATE TABLE"看建表语句是否存在；再用
mysql -e "CREATE DATABASE test_restore;"+
mysql test_restore 测试导入是否中断binlog 完整性验证：
mysqlbinlog --verify-binlog-checksum /var/lib/mysql/mysql-bin.000123 > /dev/null，返回 0 才算合格 物理备份验证：用
xbstream -x <a style="color:#f60; text-decoration:underline;" title="解压" href="https://www.php.cn/zt/18908.html" target="_blank">解压</a>后，检查 <code>xtrabackup_checkpoints中的
to_lsn是否连续
所有验证操作必须在隔离环境（Docker 或临时 VM）中完成，绝不能在生产库上解压或导入 —— 曾有团队因在生产库执行
xbstream -x占满磁盘导致二次宕机。
