mysqldump 默认导出视图定义（create view语句）而非数据，因视图是虚拟表；是否导出取决于权限、--no-create-info、--ignore-table等，与--no-data无关。
mysqldump 默认会导出视图定义，但不导出视图数据
视图在 MySQL 中是虚拟表，本身不存储数据，只保存 SELECT 查询语句。mysqldump 默认行为是把视图当作数据库对象之一，生成 CREATE VIEW 语句写入备份文件，而不是尝试“导出视图的结果集”。这意味着恢复时只要底层表存在且用户有权限，视图就能重建并正常查询。
常见错误现象：mysqldump 备份后导入报错 ERROR 1356 (HY000): View 'db.v_user' references invalid table(s) or column(s) —— 这不是 dump 本身漏了视图，而是导入时依赖的基表还没还原，或权限不足导致无法校验视图定义。
- 视图定义是否导出，取决于
--no-create-info（禁用 DDL）和--skip-triggers等开关，但跟--no-data无关（视图本来就没数据） - 若只想导出表结构+数据、跳过视图，加
--ignore-table=db_name.view_name（注意：必须写全名，且view_name要加反引号如果含特殊字符） -
mysqldump --no-data仍会输出视图的CREATE VIEW，因为它是 DDL，不是数据
导出视图时权限不足会静默跳过或报错
mysqldump 读取视图定义需要对视图本身有 SHOW VIEW 权限；若没有，行为取决于 MySQL 版本和参数：
- MySQL 5.7+ 默认遇到无权限视图会报错并中断（如
mysqldump: Got error: 1142: SELECT command denied to user ... for table 'v_log'），即使你只想要其他表 - 可用
--force让它跳过报错继续，但对应视图不会出现在 dump 文件中 —— 不会警告，也不会留占位符 - 更稳妥的做法是提前授权：
GRANT SHOW VIEW ON `db_name`.`v_name` TO 'user'@'%'; - 注意：视图定义里可能引用其他库的表，此时还需跨库权限，否则
SHOW CREATE VIEW查询本身就会失败
使用 --routines 和 --events 与视图无关，但容易混淆
有人误以为 --routines（存储过程/函数）或 --events（事件调度）会影响视图导出，其实完全独立。视图属于“普通数据库对象”，由 mysqldump 自动识别并处理，不依赖这些开关。
-
--routines只控制是否导出CREATE PROCEDURE/CREATE FUNCTION，不影响视图 -
--events只控制是否导出CREATE EVENT，也不影响视图 - 真正影响视图导出的只有：
--no-create-info、--ignore-table、权限、以及是否启用--skip-triggers（触发器和视图无关，但名字易混）
恢复时视图创建失败的典型原因
导入 dump 文件后，视图没建出来，或者建出来但查不了，往往不是 mysqldump 的问题，而是环境差异：
- 目标库缺少
DEFINER用户（比如原视图是DEFINER=`admin`@`localhost`，但目标库没这个账号）→ 解决方法：dump 时加--skip-definer，或导入前执行SET SQL_MODE='NO_AUTO_VALUE_ON_ZERO'; - 视图定义中用了 MySQL 8.0 特性（如 CTE、窗口函数），但目标库是 5.7 → 导入会报语法错误，
mysqldump不做兼容性检查 - 视图引用了临时表、FEDERATED 表或外部数据源（如 CONNECT 引擎）→ 这些对象不会被
mysqldump自动包含，需手动补全 - 导入顺序错误：先导入视图再导入基表 → 加
--databases或确保CREATE TABLE在CREATE VIEW之前
最常被忽略的是 DEFINER 权限和跨版本语法兼容性——这两点不体现在 dump 命令行里，却直接决定视图能否在新环境活下来。
