物理备份快但风险高，需停服务、环境严格一致；逻辑备份（如mysqldump）慢但安全可控，支持跨平台、可筛选修改，恢复前须注意参数配置与一致性保障。
物理拷贝快但风险高，逻辑备份（mysqldump）慢但安全可控——选哪种，取决于你能不能停服务、敢不敢赌环境一致性、以及是否接受迁移后花时间验证。
用 mysqldump 导出导入必须加 --single-transaction
不加这个参数，InnoDB 表导出时可能触发隐式锁，MyISAM 表则全程读锁，线上业务会卡顿甚至超时。它靠 MVCC 打开一个一致性快照，后续所有 SELECT 都基于该快照，写操作完全不受影响。
-
--routines和--triggers要显式带上，否则存储过程、函数、触发器全丢 - 别用
--all-databases，它会把mysql系统库也导出来，目标库权限体系不同，容易冲突甚至覆盖 root 密码 - 如果表里有大量
BLOB/TEXT，加--hex-blob，防终端或传输层截断二进制数据 - 导入前手动执行
SET FOREIGN_KEY_CHECKS = 0;，导入完再设回1；dump 文件里自带的开关不可靠，漏还原会导致外键失效 - 从 MySQL 8.0 迁到 5.7？必须加
--skip-definer和--set-gtid-purged=OFF，否则 JSON 字段、角色语法、GTID 相关语句直接报错
物理拷贝只在严格条件下才可靠
这不是“复制文件夹就完事”的操作，而是一次对齐底层环境的手术。哪怕版本号只差一个小数点（如 8.0.33 → 8.0.34），也可能因 ibdata1 格式微调导致启动失败。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须停止源库：
systemctl stop mysql，否则 InnoDB 缓冲池未刷盘，文件处于不一致状态 - 必须整套拷贝：
ibdata1、ib_logfile*、mysql/、performance_schema/、目标库目录（如myapp_db/），缺一不可 - 目标服务器的
my.cnf中关键参数要一致：尤其是innodb_file_per_table、innodb_page_size、character-set-server，否则启动时拒绝加载表空间 - 文件属主必须是
mysql:mysql，且目录权限不能是 777 —— MySQL 启动时会校验，权限过宽直接拒绝启动 - 仅适用于 XFS/ext4 等支持硬链接的文件系统；Btrfs/ZFS 上拷贝需额外加
--reflink=auto或改用rsync --sparse
迁移后必须核对 information_schema.TABLES.TABLE_ROWS
看 SHOW TABLES、查文件大小、甚至连上跑几条 SELECT COUNT(*) 都不够。真正有效的是批量比对每张表的行数统计值，误差超过 5% 就得立刻排查。
- 用这条 SQL 快速生成比对脚本：
SELECT CONCAT('SELECT ''', table_name, ''', COUNT(*) FROM ', table_schema, '.', table_name, ';') FROM information_schema.TABLES WHERE table_schema = 'db_name'; - 注意：
TABLE_ROWS是估算值，InnoDB 下不准；但源库和目标库用同一版本、同配置时，误差方向和幅度基本一致，适合快速筛查 - 如果发现某张表行数为 0，优先检查该表是否用了
ARCHIVE引擎（mysqldump默认不导）、或目标库是否禁用了对应引擎（skip-archive在 my.cnf 里） - 字符集不一致（如源 utf8mb4，目标 utf8）会导致插入时截断或报错，但
TABLE_ROWS不体现——必须抽样查具体字段内容
最常被跳过的动作是：迁移后没检查 mysql.user 表权限是否重建，也没验证远程连接是否放开 bind-address 和防火墙端口。数据在那儿，但应用连不上，问题就卡在最后一厘米。
