phpMyAdmin 4.9无法跳过损坏的MyISAM表导出，因其导出依赖逐表SELECT *，遇索引或数据文件损坏（如#1033、#126错误）即中断；可行方案是先用information_schema筛选可访问表，再通过mysqldump显式指定导出，或用--ignore-table排除已知坏表。
phpMyAdmin 4.9 无法跳过损坏的 MyISAM 表继续导出——它会在 SELECT * FROM table_name 阶段直接报错中断，必须改用命令行 + 显式排除。
为什么 phpMyAdmin 导出时遇到坏表就卡死或报错
phpMyAdmin 的「导出」功能本质是逐个执行 SELECT * 获取数据，再拼成 SQL。MyISAM 表若索引文件（.MYI）损坏、数据文件（.MYD）截断或结构不匹配，MySQL 服务端会立即返回错误，如：#1033 - Incorrect information in file: './db/t.MYI' 或 #126 - Incorrect key file for table 't'。此时 phpMyAdmin 没有重试、跳过或忽略机制，整个导出流程终止。
真正可行的绕过方式：先筛表，再用 mysqldump 显式指定
前提是 MySQL 还能连上、SHOW TABLES 可执行，但部分表 SELECT 1 FROM t LIMIT 1 失败。
- 用
information_schema列出所有表：SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_db' AND engine = 'MyISAM' - 逐个探测可访问性（bash 示例）：
mysql -Nse "SELECT table_name FROM information_schema.tables WHERE table_schema='your_db'" | while read t; do mysql -e "SELECT 1 FROM your_db.$t LIMIT 1" >/dev/null 2>&1 && echo $t; done > good_tables.txt
- 用
mysqldump导出筛选后的表：mysqldump --force --skip-triggers --skip-routines your_db $(cat good_tables.txt | xargs) > backup.sql -
--force在这里作用有限，仅防个别表触发权限/视图错误；真正起效的是“不把坏表传给 mysqldump”
MyISAM 坏表修复尝试（仅限轻度损坏）
若只是索引损坏（常见于异常关机），可尝试在线修复，但需注意权限和锁行为：
立即学习“PHP免费学习笔记（深入）”；
- 登录 MySQL 后执行：
REPAIR TABLE your_db.bad_table（仅对 MyISAM 有效，InnoDB 不支持） - 若提示
Need to create a new index file，说明索引彻底丢失，可加USE_FRM强制重建：REPAIR TABLE your_db.bad_table USE_FRM - 失败则放弃——
REPAIR TABLE对物理页损坏无效，强行运行可能扩大损坏范围 - 不要在 phpMyAdmin 界面点「操作 → 修复表」，它底层调用相同命令，失败后仍会中断后续操作
容易被忽略的关键点
MyISAM 损坏常伴随 .frm 文件与 .MYI/.MYD 元数据不一致，此时即使 REPAIR 成功，导出的表也可能含脏数据或缺失行。更稳妥的做法是：确认坏表名后，用 --ignore-table=your_db.bad_table 显式排除，优先保全其余表数据。别依赖 phpMyAdmin 的「自定义导出」勾选框——它不校验表是否可读，勾了照样崩。
