最直接的办法是使用 mysqldump 的 --ignore-table=db_name.table_name 参数多次指定要跳过的表，格式必须为库名加表名全称、大小写敏感且不可用逗号分隔。

mysqldump 里用 --ignore-table 跳过指定表

导出数据库时想排除某张超大的日志表（比如 log_detail），最直接的办法就是用 mysqldump 自带的 --ignore-table 参数。它支持多次使用，一次跳过一张表。

常见错误是写错格式：必须是 db_name.table_name 全名，不能只写表名；大小写要和实际一致（尤其在 Linux 上）；多个表要重复写多次该参数，不能用逗号分隔。

• mysqldump -u root -p myapp --ignore-table=myapp.log_detail --ignore-table=myapp.audit_log > backup.sql
• 如果库名含特殊字符或空格，用反引号包裹：--ignore-table=`my-app`.log_detail
• 不加 --ignore-table 时，mysqldump 默认导出所有表；加了就严格按列表过滤，不会“自动推断”或“模糊匹配”

用 --tables 显式列出要导出的表（替代方案）

当需要跳过的表很多、而要保留的表较少时，--tables 更可控——它只导出显式列出的表，其余全忽略。

这个方式绕过了“忽略逻辑”，从源头上避免漏配或误配，适合运维脚本固化场景。但缺点是每次新增表都要手动更新命令，维护成本略高。

• mysqldump -u root -p myapp --tables user order product > backup.sql
• 注意：--tables 后面的表名不用带库名，且必须是当前库内的表
• 如果混用 --tables 和 --ignore-table，后者会被忽略——mysqldump 以 --tables 为准

导出前检查表大小，避免误删关键数据

日志表体积大，但未必都能随便跳过。有些业务会从日志表反查异常、做审计或补数，跳过前得确认它是否真“只读”且“可重建”。

执行前建议快速看下这张表是不是空的、有没有外键依赖、最近是否有写入——否则导出文件看似成功，恢复时可能报错或丢数据。

• 查大小：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;（假设字段存在）

Docker 或自动化脚本里要注意路径与权限问题

在容器或 CI/CD 流水线中调用 mysqldump，容易卡在权限或网络连通性上，而不是配置本身。

--ignore-table 参数本身无特殊权限要求，但整个命令能否执行成功，取决于 MySQL 用户是否有 SELECT 权限（对要导出的每张表）、以及是否能访问目标库。跳过某张表不会降低权限需求。

• Docker 内执行时，确保 MySQL 客户端已安装：apt-get install mysql-client（Debian 系）
• 远程导出需确认 host 允许连接，且用户有对应库的权限：GRANT SELECT ON myapp.* TO 'backup_user'@'%';
• 输出重定向到文件时，宿主机路径需挂载进容器，否则 > backup.sql 可能写到容器临时文件系统里，一退出就丢了

最容易被忽略的是：日志表如果用了分区（PARTITION），--ignore-table 仍按整表生效，不会只跳某个分区；另外，某些备份工具（如 Percona XtraBackup）不支持类似语法，得换用其他机制。