表提示“table 'xxx' doesn't exist”但show tables可见，通常是myisam的.frm/.myd/.myi文件脱节或innodb的ibdata1与数据字典不同步所致；需先查引擎类型，再按myisam或innodb分别检查文件完整性、权限及一致性，严禁手动修改二进制文件，优先用mysqlcheck修复或innodb_force_recovery导出数据，最终依赖可靠备份恢复。
表提示 Table 'xxx' doesn't exist 但 SHOW TABLES 能看到
这通常是存储引擎元数据不一致导致的，尤其常见于 MyISAM 表的 .frm 和 .MYD/.MYI 文件脱节，或 InnoDB 的 ibdata1 与数据字典（mysql.ibd 或独立表空间）不同步。
- 先确认引擎类型：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';
- 若为
MyISAM：检查对应数据库目录下是否存在your_table.frm、your_table.MYD、your_table.MYI三个文件，缺一即无法打开 - 若为
InnoDB且启用了innodb_file_per_table=ON：确认your_table.ibd文件存在且权限正确（属主为mysql用户），同时.frm文件也必须存在 - 不要手动删除或替换这些文件——MySQL 启动时会校验 checksum，异常文件可能直接导致 mysqld 拒绝启动
ERROR 1033 (HY000): Incorrect information in file: './db/t.frm'
这是典型的 .frm 文件损坏或版本不兼容。MySQL 5.7+ 的 .frm 格式与 8.0 不互通，跨版本还原或强制拷贝容易触发此错。
- 优先尝试用
mysqlcheck修复：mysqlcheck -u root -p --repair your_db your_table
- 若报错 “Storage engine not supported” 或修复无效，说明表结构定义已损坏，需从备份恢复
.frm文件（注意：仅适用于 MyISAM；InnoDB 的.frm在 5.7+ 已被数据字典取代，不能单独恢复） - 切勿用文本编辑器修改
.frm文件——它是二进制格式，肉眼不可读
InnoDB 表显示 Table is marked as crashed 或启动时报 Cannot open table
本质是 InnoDB 的事务日志（ib_logfile*）、系统表空间（ibdata1）或独立表空间（*.ibd）出现页损坏或 LSN 不匹配。
- 检查错误日志中是否含
Database page corruption或LSN mismatch关键词，这决定了能否安全恢复 - 若只是标记为 crashed（常见于异常关机后），可尝试强制重启 + 设置
innodb_force_recovery=1到6（从低往高试），再用mysqldump导出数据 -
innodb_force_recovery > 4时禁止写入，且可能跳过部分索引重建——导出后务必重建整库，不要继续运行 - 没有备份又无法启动？可借助
innodb-tools（如ibdconnect、innochecksum）验证.ibd完整性，但成功率取决于损坏位置
误删了 .ibd 文件但 .frm 还在，能找回数据吗？
不能直接“恢复”，但有抢救路径：InnoDB 的数据实际还留在 ibdata1（如果未启用 innodb_file_per_table）或仍在内存/双写缓冲区中（极短时间窗口）。
- 立即停止所有写操作，避免覆盖——
FLUSH TABLES WITH READ LOCK;并停掉应用 - 若启用了
innodb_file_per_table=ON且.ibd已删：只要没被磁盘覆盖，可用extundelete（ext4）或photorec尝试恢复.ibd文件（注意恢复到其他磁盘，避免覆写） - 恢复后不能直接放回原目录！需先用
ALTER TABLE t DISCARD TABLESPACE;清空当前表空间，再ALTER TABLE t IMPORT TABLESPACE;导入（要求.ibd的 space_id 与数据字典一致，否则报错Tablespace mismatch） - space_id 不匹配？只能靠备份或 binlog 回滚——
.ibd文件本身不包含逻辑表名和列定义，它只认 ID
innodb_checksum_algorithm=crc32 + 避免在运行中移动或 chmod 数据文件。
