小于10gb、允许停机5分钟以内，用mysqldump+mysql是最稳的选择；超过100gb或要求秒级切换，必须放弃逻辑导出，走主从复制或percona xtrabackup。
直接回答：小于10GB、允许停机5分钟以内，用 mysqldump + mysql 是最稳的选择；超过100GB或要求秒级切换，必须放弃逻辑导出，走主从复制或 Percona XtraBackup。
mysqldump 导出时漏掉这几个参数，导入后大概率丢数据
默认只跑 mysqldump -u root -p db_name > backup.sql，几乎必然出问题。InnoDB 表可能导出中途写入导致不一致，存储过程、触发器、事件全丢，字符集还可能错乱。
-
--single-transaction：仅对 InnoDB 表生效，加它才能拿到一致性快照；含 MyISAM 表必须换--lock-all-tables -
--routines --triggers --events：三个必须一起加，缺一个就少一类对象 -
--set-gtid-purged=OFF：目标库没开 GTID（比如 MySQL 5.6 或云厂商托管实例）时必须关，否则报ERROR 1840 (HY000) -
--default-character-set=utf8mb4：强制指定字符集，避免源库character_set_client异常导致导出乱码
导入前目标库不检查这三项，90% 会卡在中途失败
不是导入命令写错了，而是目标库“看起来能连，实际不能执行”。常见失败点根本不在 SQL 文件里。
- 执行
SHOW VARIABLES LIKE 'sql_mode';，确认没启用STRICT_TRANS_TABLES——否则含零日期或空字符串的字段直接中断 - 查
max_allowed_packet值，确保 ≥ 导出文件中最大单行长度（可用head -n 100 backup.sql | wc -L估算），否则导入无声卡死 - 核对
innodb_log_file_size是否与源库一致——若不一致且旧日志文件未清理，MySQL 启动直接拒绝加载，报InnoDB: Error: log file ./ib_logfile0 is of different size
大表导入慢？问题不在磁盘，而在 autocommit 默认开着
导入 1GB+ SQL 文件时，每条 INSERT 都单独提交，性能暴跌 5–10 倍。这不是配置问题，是客户端默认行为。
- 导入前加
SET unique_checks=0; SET foreign_key_checks=0;，提速 30%–60%，导入完再设回=1 - 别用 MySQL CLI 的
source backup.sql——它单行解析、无缓冲，大文件容易内存溢出 - 改用 shell 管道：
mysql -u user -p db_name ，更稳定、更高效 - 导出时加
--skip-extended-insert可减少单行长度，但会增大文件体积；导入时加--force可跳过个别错误继续执行（慎用）
跨版本迁移最容易被忽略的兼容性断点
MySQL 5.7 → 8.0 表面平滑，实际埋着多个隐性坑。字符集、默认排序规则、系统表结构、SQL 模式都变了。
- MySQL 8.0 默认字符集是
utf8mb4_0900_ai_ci，5.7 是utf8mb4_general_ci，建库时不显式指定会导致后续比较行为不一致 - 8.0 移除了
query_cache_type等参数，my.cnf 里保留会启动失败 - 系统库
mysql不建议用--all-databases直接导出覆盖，权限表结构已变，极易导致用户无法登录 - 如果源库用了
CREATE FUNCTION且定义体含非确定性函数（如NOW()），8.0 会拒绝创建，需手动加DETERMINISTIC或NO SQL
真正难的不是命令怎么敲，而是判断该不该停库、要不要切主从、哪类对象必须人工校验——这些没法靠工具自动识别，得看数据量、停机窗口和业务容忍度来权衡。
