冷备份必须停掉mysqld进程，否则InnoDB文件状态不一致导致启动失败；需确认进程彻底退出、完整拷贝datadir和my.cnf、恢复时清空目标目录并修正权限。
冷备份时MySQL仍在运行会导致文件不一致
直接复制 /var/lib/mysql 或 C:\ProgramData\MySQL\MySQL Server 8.0\Data 目录时，如果 mysqld 进程还在跑，InnoDB 的数据文件（如 ibdata1、ib_logfile*）可能正被写入，而操作系统层面的文件拷贝无法保证原子性。结果就是：备份里可能包含部分刷新到磁盘的页、未刷盘的脏页、甚至被截断的日志段——恢复后 mysqld 启动失败或报错 innodb: Database page corruption on disk。
FLUSH TABLES 不等于安全冷备
有人误以为执行 FLUSH TABLES 或 FLUSH TABLES WITH READ LOCK 就能安全复制文件，这是危险的误解：
-
FLUSH TABLES只强制刷出表缓存，不保证 InnoDB 的缓冲池已全部落盘，也不影响 redo log 的持续写入； -
FLUSH TABLES WITH READ LOCK对 MyISAM 有效，但对 InnoDB 表只阻塞 DDL，DML 仍可能通过其他连接写入，且无法阻止后台线程（如 master thread）的刷盘行为； - 即使加锁，
ib_logfile*和ibdata1仍处于活跃 I/O 状态，复制过程极易损坏。
Windows 下 net stop mysql80 为什么有时不生效？
在 Windows 上用 net stop mysql80 停服务，常见失败原因有：
- 服务名实际是
MySQL80（带数字），但注册表或服务管理器里显示为“MySQL80”或“MySQL80 (MySQL Server 8.0)”——必须严格匹配服务名，可用sc queryex type= service state= all | findstr "mysql"查看真实名称； - MySQL 进程被第三方工具（如 MySQL Workbench、Navicat）保持连接，导致服务拒绝关闭；
- 服务依赖项（如 Windows Event Log）未响应，需检查
services.msc中服务状态是否为“已停止”，而非“停止中”。
替代方案不是“不关库”，而是换方法
若业务不能停机，冷备就不是选项，必须转向热备工具：
-
mysqldump是逻辑备份，适合中小库，但备份期间会加全局读锁（--single-transaction可缓解，仅对 InnoDB 有效）； -
Percona XtraBackup是真正的物理热备，它通过捕获并重放 redo log 来保证一致性，无需停库，但要求 MySQL 版本与 XtraBackup 版本严格兼容； - 基于
binlog的增量备份必须搭配全量备份使用，单独cpbinlog 文件无意义，且恢复时需按顺序重放。
真正容易被忽略的点是：冷备不是“简单粗暴就能用”，而是对停机窗口、文件系统一致性、权限和路径大小写的强依赖——哪怕 xcopy 多了一个 /K 参数（保留属性），也可能让恢复时因权限丢失而启动失败。
