导入SQL时提示“Table 'xxx' doesn't exist”主因是视图依赖的底表缺失、大小写不一致、DEFINER用户不存在、视图创建顺序错误或字符集/sql_mode不兼容，需逐项排查。
导入 SQL 时提示 Table 'xxx' doesn't exist
这是最常见的情况：你导出的视图依赖某个表，但导入目标库没建这个表，或者表名大小写不一致（尤其在 linux 环境下）。mysql 创建视图时不会检查底表是否存在，但执行 create view 语句时会校验——如果底表不存在，直接报错。
实操建议：
- 先用
SHOW TABLES;确认所有底表已存在，且名字和视图定义里写的完全一致（包括下划线、大小写） - 导出时加
--skip-triggers --skip-routines --skip-events，避免干扰；但必须保留--skip-views的反向操作——即**不要跳过视图**，否则你根本导不出视图语句 - 如果底表是分区表或临时表，它们无法被视图引用，导入前得先确认是否误用了这类对象
DEFINER = 'user'@'host' 导致视图创建失败
视图带 DEFINER 属性时，MySQL 要求该用户在目标库中存在，且有对应权限。本地导出的视图常带 DEFINER = 'dev'@'localhost'，而生产库根本没有 dev 用户，就会卡住。
实操建议：
- 导入前用文本工具全局替换：把所有
DEFINER = '.*?'@'.*?'替成DEFINER = CURRENT_USER（推荐）或直接删掉整段DEFINER = ...（MySQL 会自动设为当前登录用户） - 别用
mysqldump --user=root直接导出再往无 root 权限的环境导，容易埋 Definer 雷 - 如果必须保留原 Definer，得提前在目标库运行
CREATE USER 'user'@'host'; GRANT ...，但多数场景没必要
视图创建顺序引发的依赖错误
视图 A 依赖视图 B，但 SQL 文件里 B 在 A 后面才建，MySQL 就会报 Unknown table——它把视图也当“表”查了依赖链。
实操建议：
- 导出时加
--order-by-primary没用，视图不走这个逻辑；正确做法是用mysqldump --no-create-info --skip-triggers单独导结构，再手动调序 - 更稳的方式：先用
SELECT TABLE_NAME, VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'db_name';查出所有视图定义，按依赖关系拓扑排序（可用 Python 简单写个依赖解析） - 实在不想排，就分两轮导入：第一轮只建表和函数，第二轮再建视图，并确保
sql_mode包含NO_AUTO_CREATE_USER（避免 Definer 再惹事）
字符集或 sql_mode 不一致触发隐式失败
开发库用 utf8mb4_0900_as_cs，生产库还是 utf8mb4_general_ci，或者 sql_mode 缺了 STRICT_TRANS_TABLES，都可能导致视图语法看似合法，实际创建后查询时报错，甚至创建时静默失败（比如字段别名含保留字却没打引号）。
实操建议：
- 导入前在目标库执行
SELECT @@sql_mode, @@character_set_database, @@collation_database;，和源库比对 - 在导入命令里显式指定：
mysql --default-character-set=utf8mb4 --init-command="SET sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'" - 检查视图定义里有没有用到
JSON_EXTRACT、GENERATED COLUMN这类高版本特性，低版本 MySQL 会直接拒创
