Navicat备份报“Table 'xxx' doesn't exist”但表实际存在，主因是扫描到无效视图或mysql.proc等系统元数据损坏；应先确认xxx是否为系统对象，再清理无效视图或运行mysql_upgrade修复。
Navicat 备份时报 Table 'xxx' doesn't exist，但表明明存在
这大概率不是表真丢了，而是 navicat 在生成备份 sql 时扫描了 information_schema.views 或 mysql.proc 等系统对象，结果遇到一个「挂着名、没实体」的无效视图或存储过程——比如视图依赖的基表已被删，但视图定义还留在 mysql 库里；或者 mysql 升级后未运行 mysql_upgrade，导致 mysql.proc 表结构缺失。
- 先确认报错中提到的
xxx是不是你自己的业务表名：如果不是（比如是mysql.proc、sys.schema_table_statistics_with_buffer），基本可锁定为系统元数据损坏或残留对象 - 在 Navicat 中右键目标数据库 → «对象信息» → 切到 «视图» 标签页，看有没有状态异常（灰色、带感叹号）或名称可疑（含临时前缀、乱码、明显已弃用）的视图
- 执行
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'your_db_name';，再逐个SHOW CREATE VIEW `view_name`;，检查是否报错或返回空 —— 报错即为无效视图
手动清理残留视图：DROP VIEW IF EXISTS `xxx`
找到无效视图后，不能靠 Navicat 图形界面删（它可能根本列不出来或删不动），必须用 SQL 直接清理。注意：操作前务必备份整个数据库，尤其是 mysql 系统库。
- 对普通业务库中的无效视图：直接执行
DROP VIEW IF EXISTS `bad_view_name`;，无需加库名前缀 - 若报错
ERROR 1356 (HY000): View 'mysql.xxx' references invalid table(s) or column(s)，说明是系统库里的坏视图，需先用管理员账号登录，再执行USE mysql; DROP VIEW IF EXISTS `xxx`; - MySQL 8.0+ 中部分
sys库视图是只读的，不要硬删；重点清理你自己创建过、后来删了基表却忘了删视图的那些
修复 mysql.proc 缺失导致的 Table 'mysql.proc' doesn't exist
这个错误常见于 MySQL 小版本升级（如 5.7.x → 8.0.x）后未更新系统表，Navicat 调用存储过程相关元数据时崩在 mysql.proc 上。
- 停止 MySQL 服务，命令行进入
bin/目录，运行mysql_upgrade -u root -p --force，输入密码后等待完成 - 重启 MySQL 服务，再进 Navicat 尝试备份 —— 此时
mysql.proc表应已重建（MySQL 8.0+ 实际已用mysql.routines替代，但兼容层仍需该表存在） - 如果
mysql_upgrade报权限错，确认 root 用户有CREATE ROUTINE和ALTER ROUTINE权限，或临时用--skip-grant-tables启动后修复
备份时跳过系统库和问题对象的临时方案
当清理不及时或环境受限（如只读实例），又急需导出业务数据，可以绕过报错源头。
- Navicat 导出向导中，取消勾选 «系统数据库»（
information_schema、mysql、performance_schema、sys） - 在 «高级» 选项卡里，把 «导出视图» 改成 «不导出»，或手动取消勾选所有可疑视图
- 更稳妥的做法：改用命令行
mysqldump --no-create-info --skip-triggers --skip-routines your_db_name > data.sql，先保数据，再单独处理结构
真正麻烦的从来不是“表不存在”，而是 Navicat 默认把系统元数据当健康指标来校验。一旦视图、过程、事件这些逻辑对象出现定义残缺，它就会在备份、同步、甚至只是展开数据库节点时卡住。清理动作本身很简单，难的是定位哪个对象在拖后腿 —— 建议养成定期 SELECT * FROM INFORMATION_SCHEMA.VIEWS WHERE CHECK_OPTION = 'NONE' 这类语句巡检的习惯。
