error 1146 是因 create view 先于基表执行所致，mysql 解析时即校验依赖表存在性；应分两轮导入：先表后视图，或用 sed/awk 拆分 sql 文件分别执行。
mysql 导入时报错 error 1146 (42s02): table 'db.table_name' doesn't exist
这个报错不是表真丢了，而是导入顺序错了——create view 语句先于它所依赖的基表执行。mysql 解析视图定义时会立即校验底层表是否存在，不等你后续建表。
常见场景：用 mysqldump --all-databases 或导出整个 schema 后重放 SQL；或手动拼接了多个 .sql 文件按字典序导入（比如 01_views.sql 在 02_tables.sql 前）。
- 视图定义里写的表名必须在
CREATE VIEW执行前已存在，否则直接失败 -
DEFINER用户权限不影响该错误，只影响后续查询时的权限检查 - 即使加了
IF NOT EXISTS，对CREATE VIEW也无效——它不解决依赖缺失问题
怎么让视图在基表建好后再创建（不改 dump 文件）
最稳妥的做法是分两轮导入：先建库、建表、建存储过程/函数；再建视图、触发器、外键约束。靠人工拆分容易漏，推荐用工具预处理。
实操建议：
- 用
sed或awk抽出所有CREATE VIEW语句到单独文件：grep -n '^CREATE VIEW' full_dump.sql | cut -d: -f1定位行号，再用sed -n '123,125p' full_dump.sql > views.sql - 用
mysql分批执行：mysql -u root db_name ，再 <code>mysql -u root db_name - 如果 dump 文件带
USE db_name;，确保两次都指定同一库名，避免视图建到错库
mysqldump 导出时怎么避免依赖问题
默认 mysqldump 不保证对象创建顺序，尤其跨库视图或含 DEFINER 时更易出错。关键参数就两个：
- 加
--skip-triggers和--skip-routines可减少干扰，但视图仍需手动处理 - 真正有效的是
--skip-tz-utc --skip-comments --no-tablespaces这类纯数据向参数，不解决顺序问题 - 唯一能控制顺序的，是用
--skip-extended-insert+ 后续脚本按类型分组，但不如导出后拆分来得直接
结论：不要指望单条 mysqldump 命令导出即能无脑重放。生产环境应固定使用 --databases + 显式指定库名，并接受“视图需二次注入”这一事实。
恢复时遇到 View 'xxx' references invalid table(s) or column(s)
这是视图创建成功了，但查的时候报的错，和 1146 不同。说明表存在，但字段名变了、删了，或用了不存在的别名。
排查重点：
- 进 MySQL 执行
SHOW CREATE VIEW `view_name`;，看定义里引用的表和列是否还存在 - 注意大小写：Linux 下表名区分大小写，
SELECT * FROM User和SELECT * FROM user是两张表 - 如果原表被
RENAME TABLE过，视图不会自动更新，必须DROP后重建 - 临时方案：用
CREATE OR REPLACE VIEW覆盖，但要确认新定义逻辑正确，不能只为了过语法检查
复杂点在于：视图可能嵌套，A 视图依赖 B，B 依赖 C。一个底层表字段改名，可能引发一连串失效，必须顺藤摸瓜查 SHOW CREATE VIEW 链。
