mysqldump 默认导出视图，无需额外参数，但需确保不加--skip-views；导出触发器需--triggers（默认启用），导出函数/存储过程需--routines，解决DEFINER权限问题应使用--skip-definer。
mysqldump 默认不导出视图定义，必须加 --no-create-info 或 --skip-triggers 吗？
不是。默认情况下 mysqldump 会导出视图，但有个关键前提：你得用 --routines（导出存储过程/函数）和 --triggers（导出触发器）——而视图本身不需要额外开关，只要不加 --skip-views 就行。
容易踩的坑是误以为视图像触发器一样需要显式开启，结果漏掉 --triggers 却以为“视图已备份”，实际触发器一行都没进 SQL 文件。
-
--skip-views是关闭视图导出的开关，**默认不启用**，所以通常不用管 -
--triggers是导出触发器的开关，**默认启用**，但某些旧版本 MySQL 或特定权限下可能被禁用 - 如果目标库有
DEFINER权限限制，导出的视图 SQL 可能含DEFINER=`user`@`host`，还原时容易报错Access denied; you need (at least one of) the SUPER privilege(s) - 解决 DEFINER 问题最稳的方式是加
--skip-definer（MySQL 5.7.8+）或用sed替换，而不是靠--no-create-info——后者会删掉建表语句，完全不可取
备份带触发器的表时，--triggers 和 --skip-triggers 怎么选？
绝大多数情况直接用 --triggers（它本来就是默认值），除非你明确想跳过触发器逻辑。
注意：触发器是绑定在具体表上的，所以如果你只 dump 某几张表（比如 mysqldump db t1 t2），那只有这些表关联的触发器会被导出；如果 dump 整库（mysqldump db），所有触发器都会进来。
- 用
--skip-triggers会导致触发器定义彻底消失，还原后表存在但行为缺失，线上环境慎用 - 若还原库权限受限（如无 SUPER 权限），触发器创建会失败，错误信息类似：
ERROR 1227 (42000) at line XXX: Access denied; you need the SUPER privilege for this operation - 临时绕过方法：dump 时加
--skip-definer，或还原前手动删掉 SQL 文件里所有DEFINER=...字段
视图依赖其他视图或函数时，mysqldump 会自动处理依赖顺序吗？
不会。mysqldump 按字典序输出对象，不分析依赖关系。如果 v2 依赖 v1，而 v1 在文件里排在后面，还原时 CREATE VIEW v2 就会报错 Unknown table 'db.v1'。
这不是 bug，是设计使然——mysqldump 不做依赖解析，也不保证可重入性。
- 单库备份时，可通过
--skip-extended-insert+ 手动调整顺序应急，但不推荐长期依赖 - 更可靠的做法是还原前用
mysql -e "SHOW CREATE VIEW v1;"等命令确认依赖链，再按需拆分或补全 - 如果用了函数或存储过程，记得必须加
--routines，否则视图里调用的函数不存在，CREATE VIEW 直接失败
生产环境 dump 视图+触发器，必须加的最小参数集是什么？
核心就三个：--triggers、--routines、--skip-definer。其它如 --single-transaction 或 --lock-tables 属于一致性控制，和“能否导出视图/触发器”无关。
示例命令：
mysqldump --triggers --routines --skip-definer --databases mydb > backup.sql
-
--triggers：确保触发器写入（尽管默认开启，显式写出更清晰） -
--routines：覆盖视图中可能调用的函数或过程（尤其当视图含CALL或自定义函数时） -
--skip-definer：避免还原时报权限错误，比事后 sed 更可控 - 别加
--no-create-info：它会砍掉所有CREATE TABLE，视图虽在，但底表没了，备份等于废的
真正容易被忽略的是：视图本身没数据，但它的定义依赖底层表结构。dump 时如果漏了某张基础表，或者还原顺序错乱，视图即使成功创建，查询也会立刻报错。备份不是拼凑一堆 SQL，而是维护一套可闭环还原的逻辑单元。
