优先选mysqldump，除非MySQL 5.7.8+且需并行导出、跳过库或JSON元数据；mysqlpump存在版本兼容性差、视图/存储过程导出易错等问题。
MySQL数据导出时用mysqldump还是mysqlpump？
直接选mysqldump，除非你用的是 MySQL 5.7.8+ 且确定要并行导出、跳过某些库或需要 JSON 格式元数据。新版本的mysqlpump虽支持多线程和更细粒度控制，但默认不兼容低版本 MySQL（比如目标服务器是 5.6），且对视图、存储过程的处理容易出错。
常见错误现象：mysqlpump导出后在旧版 MySQL 恢复时报Unknown error 1064，其实是语法不兼容；或者恢复时卡在某个视图定义上，因为mysqlpump默认导出CREATE ALGORITHM=TEMPTABLE语句，而目标实例不支持。
- 生产环境升级换硬件，优先用
mysqldump --single-transaction --routines --triggers --events - 避免用
--all-databases，改用--databases db1 db2显式指定，防止误导系统库（如mysql库含用户权限，直接恢复会覆盖新服务器配置） - 如果表里有大量 BLOB 或长文本，加
--hex-blob避免字符集转换问题
备份文件传到新服务器前要不要校验？
要，而且必须做——不是“建议”，是防止恢复中途失败白忙活的关键步骤。网络传输、磁盘写入、编码转换都可能让 SQL 文件出现静默损坏，尤其大文件（>1GB）。
使用场景：从旧服务器/data/backup/all.sql拷到新服务器/tmp/后，不能直接mysql 。
- 用
md5sum或sha256sum在两边分别计算哈希，确保一致 - 用
head -n 100 /tmp/all.sql确认开头是/*!40101 SET @OLD_CHARACTER_SET_CLIENT=...*/这类合法 dump 头，排除空文件或截断 - 执行
mysql --no-defaults -e "SELECT 1"验证新服务器 MySQL 进程可连，再用mysql --no-defaults -e "SHOW DATABASES;"确认基础权限没被锁死
恢复时mysql命令怎么避免超时和乱码？
默认mysql客户端连接后，遇到大 SQL 文件会因等待响应超时中断，且如果源库字符集是utf8mb4而客户端没声明，中文字段可能变成问号或乱码。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
参数差异直接影响成败：不设--max-allowed-packet，遇到单条超 4MB 的 INSERT 就报错Got a packet bigger than 'max_allowed_packet' bytes；不设--default-character-set，SET NAMES语句可能被忽略。
- 恢复命令必须带：
mysql --default-character-set=utf8mb4 --max-allowed-packet=512M --net-buffer-length=1M -
--net-buffer-length调大能减少网络分包次数，对千兆内网有效；但别设太高（如 1G），MySQL 会分配对应内存，小内存服务器可能 OOM - 如果恢复中途断了，不要重跑整条命令——先用
tail -n +123456 /tmp/all.sql > /tmp/resume.sql跳过已执行行数（查日志或用grep -n "^INSERT INTO \`db1\`" /tmp/all.sql | head -1定位）
恢复完为什么SELECT COUNT(*)很快但WHERE查询很慢？
因为mysqldump导出的 SQL 默认不含索引重建逻辑，恢复后表虽然数据全，但二级索引是“懒加载”的——首次查询才触发构建，而大表索引构建可能卡住查询线程，表现就是某条WHERE语句执行几秒甚至几十秒，之后又变快。
性能影响明显：一个 5000 万行的user_log表，恢复后第一次SELECT * FROM user_log WHERE create_time > '2024-01-01'可能耗时 22 秒，第二次只要 0.03 秒。
- 恢复完成后立刻执行：
mysql -e "SELECT CONCAT('ALTER TABLE ', table_schema, '.', table_name, ' ENGINE=InnoDB;') FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys') AND engine='InnoDB';" > rebuild.sql，然后mysql ——这会强制重建聚簇索引和所有二级索引 - 别用
OPTIMIZE TABLE，它在 MySQL 5.6+ 对 InnoDB 实际只做ALTER TABLE ... FORCE，效果等同但语义模糊 - 如果磁盘 I/O 瓶颈严重，加
--innodb-flush-log-at-trx-commit=2临时降低刷盘频率（仅限恢复期间），恢复完记得改回 1
最易被忽略的是：新服务器的innodb_buffer_pool_size如果还沿用旧配置（比如只设了 128M），即使数据全在内存里，索引页频繁换入换出也会拖慢所有查询。换硬件后必须按新内存比例重调这个值，否则后续优化全在打补丁。
