MySQL报错Got error 12或Input/output error时，需先通过dmesg、smartctl和dd测试确认是否为真实硬盘故障，再结合错误可复现性及系统日志综合判断。
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，而是冻结写入、保现场、再诊断。
