mysqldump 备份卡顿应据引擎选参数：纯 innodb 用 –single-transaction；混用引擎则 –lock-tables=false 并接受轻度不一致；pg_dump 大库需 -j 并行、禁 –inserts、跳非必要元数据；管道压缩+流式校验防中断；定时脚本须用绝对路径、重定向 stderr、内置清理。
mysqldump 备份时锁表导致业务卡顿怎么办
默认 mysqldump 对 InnoDB 表加 --single-transaction 就够用，不锁表；但一旦遇到 MyISAM 表、或显式用了 --lock-tables，就会全库只读，Web 请求明显变慢甚至超时。
实操建议：
- 确认引擎类型：
select TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db'; - 纯 InnoDB 库：强制加
--single-transaction --no-tablespaces，避免临时表空间干扰 - 混用引擎（如含 MyISAM 的系统表或老业务表）：改用
--lock-tables=false+--skip-lock-tables，但必须接受备份期间可能有少量不一致（比如用户刚充值完、订单状态没同步到日志表） - 别在高峰时段跑全库 dump，尤其带
--all-databases—— 它会连information_schema一起扫，IO 压力翻倍
pg_dump 导出大库慢、内存爆掉怎么调
pg_dump 默认单连接、单事务导出，100GB+ 数据容易 OOM 或卡死在 SELECT * FROM pg_class 阶段，不是磁盘慢，是 postgresql 自身元数据查询被阻塞了。
实操建议：
- 加
-j 4启用并行导出（仅支持目录格式-Fd），把单表拆成多个文件并发拉，速度提升 2–3 倍 - 避免
--inserts：它把每行转成 INSERT 语句，文本体积膨胀 5 倍以上，恢复时解析压力极大；用默认的 copy 格式即可 - 大库跳过统计信息：
--no-tablespaces --no-owner --no-privileges，这些字段对恢复非必需，省下 10%~20% 时间 - 别用
pg_dump -c（带 DROP），恢复时锁更久；生产环境应手动控制重建顺序
备份文件压缩与校验不能靠后补
等 mysqldump 或 pg_dump 跑完再 gzip，既浪费磁盘空间（中间存一份未压缩的 SQL），又错过实时校验机会——万一磁盘写满一半就中断，你根本不知道备份是否完整。
实操建议：
- 管道直压：
pg_dump mydb | gzip > mydb_$(date +%F).sql.gz，内存占用可控，且 gzip 能及时报错（比如管道另一端断了） - 加校验：用
--format=custom（pg_dump）或--tab（mysqldump）配合md5sum流式计算，例如：pg_dump -Fc mydb | tee /tmp/backup.dump | md5sum > checksum.txt - 别信
.sql.gz文件大小：空库 dump 压缩后也可能几百 KB，得用gunzip -t或pg_restore -l快速验结构
定时备份脚本里最容易漏的三件事
crontab 里写个 0 2 * * * /backup/mysql.sh 很简单，但第二天发现备份空了、权限错了、或者日志塞满根分区——问题几乎都出在环境假设上。
实操建议：
- 绝对路径写死：
/usr/bin/pg_dump不要只写pg_dump，cron 默认 PATH 很窄，找不到命令就静默失败 - 重定向 stderr：
2>> /var/log/backup.log，否则错误（如密码过期、连接拒绝）全丢进黑洞 - 清理策略写进脚本本身：
find /backup -name "*.sql.gz" -mtime +7 -delete，别指望运维定期人工删，延迟一天就可能占爆/
备份不是“跑一次就完事”，真正麻烦的是恢复验证和权限链路。比如 pg_dump 用普通用户导出，恢复时发现没有 CREATE DATABASE 权限；或者 mysqldump 用了 --set-gtid-purged=ON，但在从库恢复直接报错。这些坑不在备份时暴露，只在灾难时刻才说话。