MySQL 报错 Got error 12 from storage engine
或 Input/output error
怎么快速定位是不是硬盘坏了
这类错误大概率指向底层 I/O 异常，但不能一上来就换硬盘——先确认是 MySQL 自身行为触发的假性 I/O 错误，还是真实硬件故障。关键看错误是否可复现、是否伴随系统级日志异常。
立刻检查dmesg -T | grep -i "ata\|nvme\|sd\|error"，出现
end_request: I/O error、
timeout、
aborted command等字样，基本可判定磁盘/控制器异常 运行
smartctl -a /dev/sdX（替换为实际设备），重点关注
Reallocated_Sector_Ct、
Current_Pending_Sector、
UDMA_CRC_Error_Count是否非零且持续增长 用
dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct测试写入是否卡住或报
Input/output error；再用
dd if=/tmp/testfile of=/dev/null bs=1M iflag=direct测试读取——任一失败即硬件层已不可靠 若 MySQL 错误只出现在特定表（如
SELECT * FROM broken_table必现 I/O 错误），而其他表正常，优先怀疑该表对应文件（
ibd或
MYD）所在区域存在坏块，而非整盘故障
MySQL 崩溃后启动失败，提示 InnoDB: Database page corruption on disk
怎么抢救数据
InnoDB 页面损坏不等于数据全丢，只要 ibdata1 和 ib_logfile* 未被覆盖，且磁盘还能读出部分扇区，就有机会提取有效记录。
停止所有写入操作，立即对整个 MySQL 数据目录做ddrescue -d -r3 /dev/sdX /mnt/rescue.img /mnt/rescue.log镜像（避免反复读取坏道） 在镜像上尝试启动 MySQL：修改
my.cnf加入
innodb_force_recovery = 1，逐级试到 6（仅 1–3 级允许 SELECT；4–6 级禁止 INSERT/UPDATE/DELETE） 能启动后，用
mysqldump --single-transaction --skip-lock-tables导出尚可访问的库表；若导出中断，改用
mysqlpump或直接拷贝
.ibd文件（需匹配 MySQL 版本和页大小） 切勿在损坏实例上执行
ALTER TABLE ... ENGINE=InnoDB或
OPTIMIZE TABLE——这些操作会强制重写页面，可能让残存数据彻底消失
使用 innodb_force_recovery
后仍无法启动，或者 mysqldump
报 Got error -1 from storage engine
说明 InnoDB 已无法解析事务日志或表空间头信息，常规恢复路径中断，必须转向二进制解析或专业工具。
用strings /var/lib/mysql/yourdb/yourtable.ibd | head -50检查是否还能看到明文字段名或业务数据——如果可见，说明数据页物理结构尚存，只是逻辑索引断裂 尝试
innodb-tools（如
ibdconnect重建表空间头，
ibd2sql直接解析 ibd 文件提取行记录），注意其对 MySQL 版本和页大小（
innodb_page_size）高度敏感 若服务器启用了 LVM，检查是否存在可用快照：
lvs -o +seg_monitor，有则立即
lvconvert --merge回滚（需逻辑卷未激活） 云环境（如 AWS RDS、阿里云 RDS）遇到此错误，应立刻停止实例并创建快照，不要自行挂载底层 EBS 卷——厂商快照机制可能保留更早时间点的干净副本
恢复后如何验证数据完整性，以及预防下次再崩
恢复不是终点，没验证的“恢复”等于没恢复；而预防的关键在于把 I/O 压力从单点硬件上卸下来。
对比恢复前后CHECKSUM TABLE your_table结果（需启用
checksum_algorithm = INNODB），不一致说明行级数据已静默损坏 用
pt-table-checksum对主从做一致性校验，重点看
Differences列是否为 0；若从库也损坏，说明问题发生在 binlog 写入前，根源在主库存储层 禁用
innodb_doublewrite是高风险操作，除非你有电池后备缓存（BBU）的 RAID 卡且确认其健康——否则务必保持开启 把
datadir迁移到支持原子写（atomic write）的 NVMe 设备，并配置
innodb_flush_method = O_DIRECT_NO_FSYNC（MySQL 8.0.14+），可绕过内核页缓存减少 I/O 路径故障点
真正棘手的不是报错本身，而是错误发生时 MySQL 还在继续接受写入——这会让坏块扩散到更多页面。所以一旦发现
Input/output error，第一反应不是重启 mysqld，而是冻结写入、保现场、再诊断。
