上一篇
场景引入:
凌晨3点,你正喝着第三杯咖啡,突然接到老板电话:“服务器要升级,2小时内把生产库的订单数据完整迁移到新机房!” 手指悬在键盘上,你突然意识到——如果导出过程出错,近半年的交易记录可能瞬间蒸发,别慌,这份保姆级MySQL导出指南能让你像拆乐高一样从容应对。
mysqldump -u用户名 -p密码 数据库名 表名 > /backup/orders_20250815.sql
注意:密码若包含特殊字符(如),建议先用mysql_config_editor
配置登录路径,避免命令行暴露。
mysqldump -uroot -p --routines --triggers --single-transaction --quick 数据库名 > full_db_backup.sql
技巧:
--single-transaction
:对InnoDB表启用事务保证一致性 --quick
:逐行导出避免内存爆满(尤其适合10GB+大表) mysqldump -d -u用户名 -p密码 数据库名 > schema_only.sql
mysqldump -u用户 -p --where="1=1 LIMIT 1000000,500000" 数据库名 表名 > chunk_2.sql
适用场景:当单表超过5GB时,通过LIMIT
分批次导出。
mysqldump --column-statistics=0 --compatible=mysql40 -uroot -p 老版本库 > compatible_backup.sql
为什么:MySQL 8.0导出到5.7时,关闭统计信息可避免导入报错。
mydumper -u 用户名 -p 密码 -B 数据库名 -T 表1,表2 -t 4 -o /backup_path
工具选择:
mysqldump
:适合<50GB数据 mydumper
:支持多线程,TB级数据首选 --single-transaction
导出MyISAM表会锁全表,线上业务直接瘫痪 --default-character-set=utf8mb4
,否则emoji表情变问号 --tz-utc=0
保持原时区,避免跨时区服务器时间错乱 FLUSH TABLES WITH READ LOCK
获取一致性位点(GTID场景) SHOW CREATE TABLE
手动验证表结构完整性 md5sum
校验备份文件是否完整 案例:将订单库从阿里云迁移到自建机房
# 1. 带GTID导出(确保主从同步连续性) mysqldump --master-data=2 --gtid -uroot -p order_db > order_db_with_gtid.sql # 2. 传输时压缩(节省70%时间) gzip -c order_db_with_gtid.sql > backup_20250815.sql.gz # 3. 目标库预处理 mysql -uroot -p -e "CREATE DATABASE order_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci" # 4. 导入时监控进度(PV工具实时显示) pv backup_20250815.sql.gz | gunzip | mysql -uroot -p order_db
性能数据(2025年实测):
mydumper
+NVMe SSD仅需23分钟 导入完成后立即执行:
-- 核对记录数是否一致 SELECT TABLE_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'order_db'; -- 随机抽查数据一致性 SELECT * FROM orders WHERE order_id IN (10001, 30045, 99999) LIMIT 3;
没验证过的备份等于没备份,现在你可以安心喝掉那杯已经凉透的咖啡了。 ☕
本文由 雍卓 于2025-08-02发表在【云服务器提供商】,文中图片由(雍卓)上传,本平台仅提供信息存储服务;作者观点、意见不代表本站立场,如有侵权,请联系我们删除;若有图片侵权,请您准备原始证明材料和公证书后联系我方删除!
本文链接:https://vps.7tqx.com/wenda/510713.html
发表评论