mysql如何高效进行全量备份_mysqldump常用参数与最佳实践-mysql教程-PHP中文网

中小型数据库指适用于中小企业的轻量级、低成本、易部署数据库系统，如MySQL、PostgreSQL、SQLite等，具备GB级数据处理能力、数百用户并发支持、高灵活性及低运维门槛，广泛用于信息管理、电商、CMS等场景。

mysql如何高效进行全量备份_mysqldump常用参数与最佳实践

对中小型数据库（mysqldump 仍是全量备份最直接、跨版本兼容性最好的选择；但默认参数极易导致锁表、丢失存储过程、恢复失败或导入混乱——关键不在“能不能用”，而在“怎么配才不踩坑”。

mysqldump --single-transaction 为什么必须加（且只对 InnoDB 有效）

不加时，mysqldump 默认会对所有表执行 FLUSH TABLES WITH READ LOCK，InnoDB 表会被全局读锁阻塞写入，业务可能卡顿数秒到数分钟。加了 --single-transaction 后，它会在事务快照中读取数据，全程无锁，写操作完全不受影响。

仅对 InnoDB/XtraDB 表生效；MyISAM 表仍会触发锁表，此时应改用 --lock-all-tables 或换物理备份
要求 MySQL 开启 autocommit=1，否则事务不会自动提交，快照可能过期
不能和 --lock-tables 或 --lock-all-tables 共存，否则报错

哪些对象默认不备份？必须显式加的三个参数

mysqldump 默认只导出表结构和数据，存储过程、触发器、事件调度器全部被忽略——恢复后功能直接缺失，但错误不会立即暴露，容易漏检。

--routines：包含 CREATE PROCEDURE 和 CREATE FUNCTION
--triggers：导出每个表关联的触发器定义
--events：备份事件调度器（如定时清理任务）
漏掉任意一个，恢复后对应逻辑就“消失”了，且无任何警告提示

--databases vs --all-databases：为什么推荐前者

--all-databases 看似省事，实则把 information_schema、performance_schema、sys 这些系统库也 dump 进来，不仅增大文件体积，还可能在恢复时报错（比如 CREATE DATABASE IF NOT EXISTS information_schema 不合法）。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

用 --databases app_db user_db 显式列出业务库，干净可控
避免恢复时因系统库权限或结构差异失败
配合 --set-gtid-purged=OFF 可防止 GTID 环境下恢复时报 GTID_PURGED cannot be changed

密码安全与脚本自动化中的硬伤点

在 shell 脚本里写 -p'password' 是高危操作：ps aux 可直接看到明文密码，历史命令、进程树、审计日志全暴露。

正确做法：创建 ~/.my.cnf，权限设为 600，内容为：

[client]
user=root
password=your_secure_password

脚本中直接调用 mysqldump --defaults-extra-file=~/.my.cnf ...，避免密码入参

若用 cron 定时，注意 ~ 在非交互 shell 中可能不展开，建议写绝对路径如 /root/.my.cnf

真正容易被忽略的不是参数本身，而是备份后没验证——mysqldump 即使遇到部分表读取失败（比如临时表损坏、权限不足），也默认继续执行并返回 0 退出码，备份文件看似完整，实际缺数据。务必在备份后抽样检查 SQL 文件头尾、执行 head -20 backup.sql | grep "CREATE TABLE"，或导入到测试库跑一次 mysqlcheck -u root -p --all-databases。