mydumper不导出视图定义，因其仅扫描INFORMATION_SCHEMA.TABLES中TABLE_TYPE='BASE TABLE'的条目，跳过'VIEW'类型，且无参数可开启视图导出；迁移超大视图需分三步：单独导出视图定义、用mydumper迁移依赖大表、手动建视图并校验依赖与权限。
mydumper 本身不导出视图定义，它只导出表结构（CREATE TABLE）和数据，对视图、存储过程、函数、事件等对象完全忽略。所以直接用 mydumper 迁移“超大MySQL视图”是无效的——视图不会出现在输出文件里。
如果你看到有人声称“用 mydumper 迁移视图”，大概率是混淆了概念：他们真正迁移的是视图所依赖的大表，而视图本身仍需单独处理。
为什么 mydumper 不导出视图
mydumper 的设计目标是高性能逻辑备份，核心逻辑是：
- 扫描
INFORMATION_SCHEMA.TABLES，只取TABLE_TYPE = 'BASE TABLE'的条目 - 跳过
'VIEW'、'SYSTEM VIEW'等类型 - 不查询
INFORMATION_SCHEMA.VIEWS，也不执行SHOW CREATE VIEW
这是硬编码行为，无法通过参数开启。即使加 --routines 或 --triggers，也对视图无效。
迁移超大视图的正确组合方案
所谓“超大视图”，通常指其底层查询涉及超大表（如几十亿行）、或计算复杂（含多层嵌套、窗口函数、GROUP BY 大基数）。迁移重点不是“搬视图本身”，而是确保：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 源视图定义能无误重建
- 所依赖的超大表已完整迁移到目标库（且结构、索引、字符集一致）
- 目标库用户有对应 SELECT 权限
推荐分三步走：
1. 单独导出视图定义：
用 SQL 查询批量生成 CREATE VIEW 语句：
SELECT CONCAT('CREATE OR REPLACE VIEW `', TABLE_SCHEMA, '`.`', TABLE_NAME, '` AS ', VIEW_DEFINITION, ';')
FROM INFORMATION_SCHEMA.VIEWS
WHERE TABLE_SCHEMA = 'your_db';2. 用 mydumper 迁移依赖的大表：
确保加关键参数避免锁表和乱码：
-
--no-locks（InnoDB 表适用） -
--skip-tz-utc防止时区转换问题 -
--default-character-set=utf8mb4显式指定字符集 - 对单张超大表可加
--tables-list指定，避免全库扫描开销
3. 手动执行视图建语句前检查：
在目标库运行前，确认：
- 所有被引用的库/表名存在（注意跨库视图中的
db_name.table_name是否目标环境有同名库） - 字段别名无冲突（
ERROR 1060“duplicate column name” 常因视图中用了SELECT *且底层表结构变更） - 用户权限已通过
GRANT SELECT ON target_db.* TO 'user'@'%';授予
常见报错与绕过方式
直接执行导出的 CREATE VIEW 语句失败，高频原因：
-
ERROR 1356 (HY000): View 'xxx' references invalid table(s) or column(s)→ 说明依赖表未就位或字段名不一致，别急着改视图，先查SHOW CREATE TABLE对比结构 -
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s)→ 目标 MySQL 8.0+ 默认禁用SQL SECURITY DEFINER，改用SQL SECURITY INVOKER或给用户加SET_USER_ID权限 -
ERROR 1071 (42000): Specified key was too long→ 视图定义里隐含了超长索引提示（罕见），实际是目标库innodb_large_prefix或页大小限制导致，需调低max_key_length或改用AUTO_INCREMENT替代
注意：mydumper 导出的 schema.sql 文件里不会有视图，别在里面找。
替代选择：什么时候该换工具
如果视图数量多、依赖关系深、还要同步函数/事件，mydumper 就不该是主力：
- 纯结构迁移（含视图）：用
mysqldump --no-data --routines --triggers your_db - 跨版本或异构迁移（如到 DM8）：必须用达梦 DTS、DataX 等带语法转换能力的工具
- 线上不停服 + 增量追平：
mydumper不支持，得上gh-ost+ binlog 解析组合
视图迁移真正的难点从来不在“导出”，而在于定义是否能在新环境下稳定执行——这取决于你对依赖表结构、权限链路、SQL_MODE 和字符集的控制力，而不是 dump 工具本身有多快。
