磁盘坏道导致表无法读取须先确认：查mysql错误日志搜“io error 5/13”、运行dmesg | grep -i "sda\|error"、用badblocks扫描，若show create table成功但select失败，说明坏道影响物理文件而非逻辑结构。
磁盘坏道导致的表无法读取，不能只修表，必须先隔离坏块、再分引擎处理——MyISAM 表可能还能在线抢救，InnoDB 表大概率要靠 innodb_force_recovery 导出数据，且修复前不备份原始文件等于放弃恢复机会。
怎么确认真是磁盘坏道，不是普通表损坏？
很多“无法读取”被误判为表损坏，实际是底层 I/O 失败。先交叉验证：
- 查 MySQL 错误日志（
/var/log/mysql/error.log或data/hostname.err），搜IO error 5、IO error 13、Operating system error number 5、Unable to read page—— 这些是磁盘层报错，不是 SQL 层问题 - 运行
dmesg | grep -i "sda|error"（把sda换成你实际磁盘名），看是否有Buffer I/O error或EXT4-fs error输出 - 用
badblocks -sv /dev/sdaX > badblocks.txt扫描分区（需卸载或只读挂载），确认物理坏块位置 - 如果
SELECT * FROM table_name LIMIT 1;报错但SHOW CREATE TABLE成功，说明表结构可读，问题更可能在 .ibd 或 .MYD 文件所在磁盘区域
MyISAM 表遇到坏道还能在线修吗？
可以试，但风险高、条件严——仅当坏道尚未破坏 .MYD 或 .FRM 文件，且 MySQL 还能连上时才适用：
- 先用
CHECK TABLE your_table;确认状态，若返回Msg_text含is marked as crashed或Incorrect key file，再继续 - 执行前必须：① 确认引擎是 MyISAM（
SHOW CREATE TABLE your_table;中含ENGINE=MyISAM）；② 备份三文件：cp /var/lib/mysql/dbname/your_table.{MYD,MYI,FRM} /backup/；③ 确保磁盘剩余空间 ≥ 表大小 × 2（EXTENDED模式会生成临时文件） - 修复命令按顺序尝试：
REPAIR TABLE your_table;→ 失败则REPAIR TABLE your_table EXTENDED;→ 再失败且 .MYI 已损，则REPAIR TABLE your_table USE_FRM;（此模式不保证索引可用，修完必须ANALYZE TABLE） - 若
REPAIR TABLE卡住超 5 分钟，或反复报Can't repair table，说明坏道已影响数据块，立刻停手，切到离线工具myisamchk
InnoDB 表卡在“Got error -1 from storage engine”怎么办？
这是典型坏道触发的存储引擎级拒绝服务，REPAIR TABLE 直接报错 ERROR 1031，必须走 innodb_force_recovery 流程：
- 第一步永远是停服务 + 全量备份：
systemctl stop mysql，然后cp -r /var/lib/mysql /var/lib/mysql_backup_$(date +%Y%m%d)—— 坏道可能随访问扩大，跳过这步后续全白忙 - 编辑
/etc/my.cnf，在[mysqld]下添加innodb_force_recovery = 1，保存后systemctl start mysql；若启动失败，依次尝试 2、3、4（level 4起进入只读模式，适合导出） - 启动成功后立刻导出数据：
mysqldump -u root -p --single-transaction dbname tablename > /tmp/table_fixed.sql；不要做任何写操作，尤其避免OPTIMIZE或ALTER - 导出完成后，注释掉
innodb_force_recovery，重启 MySQL；用新空库导入table_fixed.sql；原表空间文件（.ibd）建议直接删掉，别试图复用
为什么修完还是 SELECT 报错？关键常被忽略
最常踩的坑不是命令写错，而是没理清层级关系：
- 误把 InnoDB 表当 MyISAM 修：
SHOW CREATE TABLE必须看第二行，不是看表名或数据库名；information_schema.tables中查ENGINE字段更可靠 - 坏道位置决定能否恢复：如果坏块落在
ibdata1头部或 redo log 区域，innodb_force_recovery可能完全无效，此时只能用Percona Data Recovery Tool for InnoDB提取碎片数据 - 修复后没验证数据完整性：
CHECK TABLE返回OK不代表数据没丢，要对比修复前后Data_length和Index_length是否突变，再抽样查几条关键记录内容 - 磁盘未换就上线：坏道不会自己消失，修复只是绕过，必须更换硬盘或至少将 MySQL 数据目录迁移到健康磁盘，否则几天内必然复发
