mysqldump默认不备份视图、存储过程、函数等逻辑对象，需显式添加--routines（存储过程和函数）、--triggers（触发器）、--events（事件）等参数；视图随库导出但依赖--no-create-info未启用，还原时需注意对象创建顺序及跨库引用。
mysqldump 默认不备份视图和存储过程？
默认情况下，mysqldump 只导出表结构和数据，视图（VIEW）、存储过程（PROCEDURE）、函数（FUNCTION）、触发器（TRIGGER）等逻辑对象不会被包含——除非显式启用对应参数。这是最常被忽略的点，导致还原后视图查不到、调用存储过程报 PROCEDURE does not exist。
-
--routines：必须加上，才能导出PROCEDURE和FUNCTION -
--triggers：默认开启，但显式写上更稳妥（尤其跨版本迁移时） -
--events：如果用了事件调度器（EVENT），需额外加此参数 - 视图本身会随
--all-databases或指定库导出，但前提是不加--no-create-info且未禁用--skip-triggers类干扰选项
只备份逻辑对象（不含表数据）的实用命令
日常维护中常需要单独备份存储过程和视图定义，避免导出大量冗余数据。这时应组合使用 --no-data + --routines + --skip-triggers（防止误导触发器干扰）：
mysqldump -u root -p --no-data --routines --skip-triggers --databases mydb > mydb_logic.sql
-
--no-data排除所有表的数据行，只保留CREATE VIEW、CREATE PROCEDURE等语句 - 务必用
--databases（而非--database）以确保输出含CREATE DATABASE IF NOT EXISTS和USE语句，否则还原时可能因库不存在或上下文错乱失败 - 若只导某个视图，不能直接用
mysqldump单独处理——得用SHOW CREATE VIEW view_name手动提取
还原时视图报错 “Table doesn’t exist” 怎么办？
即使备份了视图，还原后执行 SELECT * FROM myview 仍报错，大概率是因为视图依赖的基表尚未创建，或创建顺序不对。MySQL 不保证 mysqldump 输出中视图定义一定在对应表之后。
- 检查备份文件中视图语句是否出现在其依赖表的
CREATE TABLE之后；如果不是，手动调整顺序，或分两步还原：
先用--no-routines --skip-triggers导入表结构和数据，再用--no-data --routines单独导入逻辑对象 - 视图中若引用了其他库的表（如
otherdb.t1），还原目标环境必须存在该库及表，否则CREATE VIEW会静默失败（除非加--force，但不推荐） - MySQL 8.0+ 中，视图定义里的权限检查上下文（
SQL SECURITY）会被保留，若还原到权限模型不同的环境，可能引发执行时报错
用 mysqlpump 替代 mysqldump？
mysqlpump 是 MySQL 5.7+ 引入的并行逻辑备份工具，对逻辑对象支持更清晰，参数也更直观：
mysqlpump -u root -p --exclude-databases=% --include-databases=mydb --routines --triggers --events > mydb_logic_v2.sql
-
--routines在mysqlpump中默认关闭，必须显式启用 -
--include-databases比mysqldump的--databases更安全，不会误含系统库 - 它会自动按依赖关系排序对象（如先建表、再建视图、最后建存储过程），大幅降低还原失败概率
- 注意：
mysqlpump不支持 MySQL 5.6 及更早版本，且无法跳过某些对象类型（如不能只导视图不导存储过程）
视图和存储过程这类逻辑对象的备份，关键不在“能不能导”，而在“导得全不全、还原顺不顺利”。最容易被忽略的是参数组合的副作用，比如加了 --no-create-info 就连视图定义也没了，或者没加 --routines 却以为存储过程已包含在内。实际操作前，务必用 head -20 和 grep -E "(CREATE VIEW|CREATE PROCEDURE)" 快速验证备份文件内容。
