error 1146是因视图创建时依赖的基表尚未存在所致，常见于导出重放、工具按字母序导出或手动拼接sql时执行顺序错误；应先提取视图语句，再分两轮导入。
CREATE VIEW 报 ERROR 1146：底表还没建好
视图创建失败最常见原因就是 ERROR 1146 (42S02): Table 'db.table_name' doesn't exist。这不是表真丢了，而是 CREATE VIEW 语句在它依赖的基表之前执行了。MySQL 解析视图定义时会立刻校验所有引用的表是否存在——不等你后续建表，直接报错。
典型场景包括：
• 用 mysqldump --all-databases 导出后重放
• Navicat 17 按字母序导出（比如 views.sql 在 tables.sql 前）
• 手动拼接多个 SQL 文件，没控制执行顺序
实操建议：
• 先用 grep -n '^CREATE VIEW' dump.sql 定位所有视图语句行号
• 用 sed 抽出视图到单独文件：sed -n '123,125p' dump.sql > views.sql
• 分两轮导入：mysql -u root db_name ，再 <code>mysql -u root db_name <br>• 确保两次都指定同一<a style="color:#f60; text-decoration:underline;" title="数据库" href="https://m.php.cn/zt/16015.html" target="_blank">数据库</a>名，避免 <code>USE 错位导致视图建到空库或错库
视图之间有依赖，但 SQL 文件里顺序反了
视图 A 引用了视图 B，但脚本中 B 的定义在 A 后面，MySQL 就会报 Unknown table 'B'。它把视图也当“表”查依赖，不会自动拓扑排序。
实操建议：
• 不要依赖 --order-by-primary（对视图无效）
• 查依赖关系：SELECT TABLE_NAME, VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'db_name'
• 用 Python 写个简单脚本解析 VIEW_DEFINITION 中的 FROM 和 JOIN 表名，做依赖排序
• 更快的替代方案：先只导结构（mysqldump --no-data --skip-triggers db_name），再人工按依赖调整顺序
DEFINER 用户不存在，连 CREATE VIEW 都被拦住
开发环境导出的视图带 DEFINER = 'dev'@'localhost'，但生产库没这个用户，MySQL 直接拒绝创建——不是权限问题，是用户根本不存在。
实操建议：
• 导入前全局替换：sed -i "s/DEFINER = '[^']*'@'[^']*'/DEFINER = CURRENT_USER/g" dump.sql
• 或直接删掉整段 DEFINER = ...，MySQL 会自动设为当前登录用户
• 别用 mysqldump --user=root 导出再往无 root 权限环境导，DEFINER 雷埋得又深又准
字符集、sql_mode 或大小写不一致，让错误更隐蔽
开发库用 utf8mb4_0900_as_cs，生产库还是 utf8mb4_general_ci；或者 sql_mode 缺了 STRICT_TRANS_TABLES，都可能导致视图创建看似成功，但一查就崩，甚至创建时静默失败。
实操建议：
• 导入前统一设置：SET NAMES utf8mb4; SET sql_mode = 'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER';
• Linux 下检查表名大小写：SHOW TABLES LIKE 'user_info';，必须和视图里写的完全一致（含下划线、大小写）
• 视图中引用的表名加反引号：SELECT * FROM `user_info`，防关键字冲突
复杂点往往藏在细节里：MySQL 不校验字段是否存在，但校验表是否存在；SQL Server 要求 ANSI_NULLS 必须 ON；Navicat 导出不分析语义依赖——这些都不是语法错，而是环境状态没对齐。
