--ignore-table必须严格按db_name.table_name格式逐个指定，不支持通配符或逗号分隔；推荐用--tables显式列举需导出的表，并加--default-character-set=utf8mb4和--set-gtid-purged=OFF确保兼容性。
用 --ignore-table 跳过日志或历史大表
直接加 --ignore-table=db_name.table_name 参数，每张要跳过的表都得单独写一次。它不支持通配符、不能用逗号分隔、也不接受只写表名——漏掉库名或大小写不对（尤其在 Linux 环境下），参数就完全失效。
常见错误现象：mysqldump 仍导出了目标表，或者报错 Unknown table 'xxx' in information_schema，基本都是格式没对齐。
- 正确写法：
mysqldump -u root -p myapp --ignore-table=myapp.log_detail --ignore-table=myapp.audit_2024 - 库名含短横线等特殊字符？用反引号：
--ignore-table=`my-app`.log_detail - 混用了
--tables和--ignore-table？后者会被直接忽略——mysqldump以--tables为准
跳太多表时，改用 --tables 显式列举更稳妥
当要保留的表远少于要跳过的表（比如只导 user、order，但库里有 20+ 张日志表），硬写一堆 --ignore-table 容易漏、难维护，还容易因新增表而意外导出脏数据。
这时直接用 --tables 只导你确认需要的表，逻辑更清晰，也规避了“漏配即风险”的问题。
-
--tables后面只写表名，不带库名：mysqldump -u root -p myapp --tables user order product - 表名是保留字（如
order、group）？必须加反引号：--tables user `order` `group` - 该方式不会生成
CREATE DATABASE语句，恢复时需确保目标库已存在
导出前务必确认被跳过的表是否真能“丢”
日志表体积大，但不等于可随意跳过。有些审计、补数、异常回溯流程依赖这些表，跳过会导致备份不可用，甚至恢复后业务报错。
执行前快速验证三件事：
- 查大小：
SELECT table_name, round(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.tables WHERE table_schema = 'myapp' AND table_name = 'log_detail'; - 查外键依赖：
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'log_detail'; - 查最近写入时间：
SELECT MAX(created_at) FROM log_detail;（若字段名不同，换成实际时间字段）
字符集和 GTID 配置容易被忽略
导出大表本身不慢，但乱码或 GTID 冲突会让后续恢复失败——这些问题往往在导入时才暴露，排查成本高。
建议默认加上这两项：
- 强制 UTF8MB4：
--default-character-set=utf8mb4，避免中文或 emoji 乱码；别只设客户端字符集，还得确认源表SHOW CREATE TABLE xxx中确实是CHARSET=utf8mb4 - 关闭 GTID 记录（尤其跨版本恢复）：
--set-gtid-purged=OFF，否则可能报GTID_PURGED can only be set on a server with gtid_mode = ON - 大表导出期间锁表影响业务？加
--skip-lock-tables，但需确保备份窗口内无 DDL 操作
事情说清了就结束。真正麻烦的不是命令怎么写，而是跳过哪张表、为什么能跳、跳完会不会断链——这些得看业务上下文，不是参数能自动判断的。
