mysqldump报“Table doesn't exist”但SHOW TABLES可见，通常是坏视图导致：视图引用已删表或非法字段，SHOW CREATE VIEW失败而中断，错误误导为表丢失；需查information_schema.VIEWS定位并DROP或--ignore-table跳过。
mysqldump 报错 “Table doesn't exist” 但 SHOW TABLES 能看见表
这通常不是真丢失，而是 mysqldump 在扫描依赖关系时卡在了“坏视图”上。MySQL 8.0+ 默认启用 sql_mode=STRICT_TRANS_TABLES，如果某个视图（VIEW）底层引用了已删表或非法字段，mysqldump 尝试 SHOW CREATE VIEW 时就会直接报错并中断，错误信息里却只显示“Table 'xxx' doesn't exist”，让人误以为是主表问题。
验证方法很简单：
- 手动执行
SHOW CREATE VIEW view_name;—— 如果报错，说明该视图已损坏 - 用
SELECT * FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'your_db';列出所有视图，逐个检查VIEW_DEFINITION是否含已删表名 -
mysqldump加--skip-triggers --skip-routines --skip-events后再试，若成功，基本可锁定是视图/触发器等元对象问题
如何定位哪个视图在拖后腿
别靠猜。直接查 information_schema.VIEWS 中定义体里是否包含疑似已删表名：
SELECT TABLE_NAME, VIEW_DEFINITION FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'your_db' AND VIEW_DEFINITION LIKE '%bad_table_name%';
注意：VIEW_DEFINITION 是完整 SQL 字符串，大小写敏感，且可能含反引号或数据库前缀（如 `mydb`.`bad_table`）。如果查不到，试试模糊搜字段名或用正则（MySQL 8.0+ 支持）：
SELECT TABLE_NAME FROM information_schema.VIEWS
WHERE TABLE_SCHEMA = 'your_db'
AND VIEW_DEFINITION REGEXP '(from|join)[[:space:]]+[`a-z_]+[.]{1}`?bad_table`?';一旦定位到问题视图，有两个选择：
- 临时删除它：
DROP VIEW IF EXISTS broken_view;（备份前操作，完事后可重建） - 跳过它导出：
mysqldump -u user -p your_db --ignore-table=your_db.broken_view > dump.sql
MySQL 8.0+ 数据字典导致的“假不存在”视图
从 MySQL 5.7 升级到 8.0 后，视图元数据也迁入原子数据字典。如果升级过程异常，或曾手动拷贝过 .frm 文件，可能出现：视图在 information_schema.VIEWS 里能查到，但 SHOW CREATE VIEW 报错说表不存在 —— 实际是字典注册不全。
这时不能硬删文件，得走标准清理流程：
- 先确认视图是否真在字典中：
SELECT * FROM mysql.views WHERE name = 'broken_view'; - 若存在但状态异常，用
DROP VIEW IF EXISTS broken_view;清理字典条目（不是删磁盘文件） - 再用原始
CREATE VIEW语句重建（确保底层表已恢复或替换）
注意：mysql.views 是系统表，普通用户不可见，需用 root 或 SUPER 权限账户登录操作。
备份时绕过视图和坏依赖的实操参数
生产环境不敢随便删视图？那就让 mysqldump 绕开它们：
-
--no-create-info：跳过CREATE TABLE语句，只导数据（适合已知结构稳定场景） -
--skip-triggers --skip-routines --skip-events --skip-views：四连跳，彻底避开所有元对象干扰 -
--ignore-table=db.view_name：精准忽略单个视图（注意格式是db.name，不是db.name） - 组合使用更稳：
mysqldump -u user -p --skip-views --skip-triggers your_db > clean_dump.sql
真正麻烦的不是表找不见，而是 mysqldump 在你没意识到的地方替你做了依赖解析——它会默默检查每个视图、触发器、存储过程的定义合法性，一处失效就全盘失败。排查时别只盯着表名，先看日志里报错前最后一行在查什么对象。
