WordPress大网站数据库备份
很多站点在数据量变大后，直接执行 mysqldump 备份会导致前台页面卡死，原因是默认备份会锁定数据表，影响正在写入的请求。
对于 WordPress 大网站，尤其访问量高、订单或评论写入频繁时，必须改用不锁表的方式。
本文以 InnoDB 引擎为例，讲解用 mysqldump 的 --single-transaction 参数配合 crontab 实现定时备份，全程不影响正常业务，备份文件可正常恢复。
备份前先确认引擎和权限
--single-transaction 只对 InnoDB 表有效，如果 WordPress 用了 MyISAM 表，该方法无法避免锁表。
先登录 MySQL 确认默认引擎：
mysql -u root -p -e "SHOW VARIABLES LIKE 'default_storage_engine';"接着检查 WordPress 数据库里是否有 MyISAM 表：
mysql -u root -p -e "SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='你的数据库名' AND ENGINE='MyISAM';"如果有输出，说明存在 MyISAM 表，需要先转换成 InnoDB，否则备份时仍可能锁表。
转换前做好临时备份，并选择业务低峰期操作。
另外，备份账号需要 SELECT、LOCK TABLES、SHOW VIEW、EVENT 和 TRIGGER 权限。
建议单独创建备份用户，避免使用 root 直连：
CREATE USER 'wpbackup'@'localhost' IDENTIFIED BY '强密码';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON 你的数据库名.* TO 'wpbackup'@'localhost';
FLUSH PRIVILEGES;用 single-transaction 实现不锁表备份
确认引擎和权限没问题后，手动执行一次备份命令，验证效果：
mysqldump -uwpbackup -p'强密码' --single-transaction --quick --routines --triggers --events 你的数据库名 > /data/backup/wordpress_$(date +%F).sql参数说明：
--single-transaction：在备份前开启一个事务，利用 InnoDB 的 MVCC 机制读取一致快照，不会长时间锁定数据表。--quick：逐行导出，避免大表一次性缓冲到内存里。--routines、--triggers、--events：把存储过程、触发器、事件一并备份，否则恢复后可能丢功能。$(date +%F)：生成类似2025-01-15的日期文件名，方便区分版本。
执行时观察前台页面是否正常访问。
如果站点仍出现卡顿，检查是否有大量 MyISAM 表，或者数据库本身存在长时间慢查询占用事务。
配置 crontab 定时备份并保留最近 N 天
手动备份成功后，再设置 cron 定时任务。
以每天凌晨 3 点备份为例：
crontab -e添加一行：
0 3 * * * mysqldump -uwpbackup -p'强密码' --single-transaction --quick --routines --triggers --events 你的数据库名 > /data/backup/wordpress_$(date +%F).sql 2>> /data/backup/backup_error.log && find /data/backup -name '*.sql' -mtime +7 -delete这行命令做了两件事：每天 3 点执行不锁表备份，并把报错写入日志；
同时用 find 删除 7 天前的备份文件，避免磁盘被撑爆。
如果不想把密码写在命令行，可以在家目录创建 .my.cnf 配置文件：
[mysqldump]
user=wpbackup
password=强密码然后命令简化为：
0 3 * * * mysqldump --single-transaction --quick --routines --triggers --events 你的数据库名 > /data/backup/wordpress_$(date +%F).sql记得给 .my.cnf 设置 600 权限：chmod 600 ~/.my.cnf。
恢复测试与高频问题处理
备份不能只生成不管，必须定期做恢复演练。
恢复命令如下：
mysql -u root -p 你的数据库名 < /data/backup/wordpress_2025-01-15.sql恢复后访问前台并检查文章、图片、评论是否正常，重点确认插件写入的数据表没有丢失。
常见问题中，备份文件过大导致磁盘占满时，可以改用压缩方式：mysqldump ... | gzip > wordpress_$(date +%F).sql.gz，但恢复时需要先解压。
如果备份过程报 Lock wait timeout exceeded，说明当时有长事务未提交，建议把定时任务调整到业务最低峰时段，或先排查慢查询。
使用 --single-transaction 备份 InnoDB 表不会长时间锁表，这是大流量 WordPress 站点的首选方案。
定时任务必须搭配过期清理策略，否则备份文件会持续占用磁盘。
备份完成后建议先做一次恢复测试，确认导出文件可正常导入，才算真正完成备份任务。
如果你正在处理 WordPress 大网站数据库备份的定时与锁表问题，可以按本文步骤执行，再根据实际日志调整备份时间和保留天数。
遇到异常时，优先检查表引擎和权限配置。
