MySQL 崩溃后能否恢复取决于是否开启 log_bin、InnoDB 表空间是否物理损坏及最近备份是否有效；满足 binlog 开启且有可用全量备份时，95% 场景可完整恢复。
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 如果执行时报 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 解压 后，检查xtrabackup_checkpoints中的to_lsn是否连续
所有验证操作必须在隔离环境（Docker 或临时 VM）中完成，绝不能在生产库上解压或导入 —— 曾有团队因在生产库执行 xbstream -x 占满磁盘导致二次宕机。
