不能直接mv是因为mysql启动时校验数据目录路径、结构和时间戳，mv后配置未更新会导致服务读取旧路径或误判为新实例而重建。应改配置或用软链接迁移，并同步更新selinux/apparmor策略、auto.cnf及innodb日志路径。
MySQL 升级后数据目录空间不足，为什么不能直接 mv？
升级 MySQL（尤其是跨大版本，如 5.7 → 8.0）后，mysqld 启动时可能报 Table 'mysql.user' doesn't exist 或反复初始化失败——这不是权限问题，而是因为 MySQL 服务启动时会校验数据目录下关键系统表的结构和文件时间戳。直接 mv 整个 datadir 到新位置后没重置配置，会导致服务读取旧路径、找不到文件，或误判为全新实例而覆盖重建。
用软链接迁移 datadir 的实操步骤
核心思路：保留原 datadir 路径不变（避免配置/启动脚本/SELinux 上下文等连锁变更），把真实数据挪到大空间分区，再用软链接“透传”过去。前提是原路径所在文件系统支持符号链接（ext4/xfs 均可，但某些 NFS 或只读挂载不支持）。
- 停掉 MySQL：
systemctl stop mysqld（或service mysql stop，依 init 类型而定） - 确认新位置有足够空间且属主一致：
chown -R mysql:mysql /new/path/mysql_data - 复制数据（不是移动！）：
rsync -av --progress /var/lib/mysql/ /new/path/mysql_data/（注意末尾斜杠，确保内容而非目录本身被复制） - 备份原目录并创建软链接：
mv /var/lib/mysql /var/lib/mysql.bak && ln -s /new/path/mysql_data /var/lib/mysql - 验证链接有效：
ls -l /var/lib/mysql应显示指向新路径，且mysql -e "SHOW VARIABLES LIKE 'datadir';"仍返回/var/lib/mysql
软链接方式下必须检查的三个细节
很多故障出在这些看似“无关紧要”的地方：
-
apparmor或selinux策略默认不放行新路径访问，需更新策略：Ubuntu 下编辑/etc/apparmor.d/usr.sbin.mysqld，添加/new/path/mysql_data/** rwk,；CentOS/RHEL 需执行semanage fcontext -a -t mysqld_db_t "/new/path/mysql_data(/.*)?"+restorecon -Rv /new/path/mysql_data - MySQL 配置中
pid-file、socket、log-error等路径若写死绝对路径，且恰好也在/var/lib/mysql下（如pid-file = /var/lib/mysql/mysqld.pid），软链接后它们仍能工作；但如果配置成pid-file = /var/run/mysqld/mysqld.pid就不受影响——重点看实际配置值，别想当然 -
innodb_log_group_home_dir默认和datadir同路径，如果显式设置了该参数，需同步改为新路径下的对应子目录（如/new/path/mysql_data），否则 InnoDB 启动时报InnoDB: Unable to lock ./ibdata1 error
比软链接更稳的替代方案：修改 my.cnf 中的 datadir
软链接简单，但排查链路长、依赖文件系统特性。生产环境更推荐直接改配置：
- 在
my.cnf的[mysqld]段落明确设置：datadir = /new/path/mysql_data - 同时更新
socket、pid-file、log-error等路径（尤其socket，客户端连接常因此失败） - 复制数据后，**必须**同步复制
mysql系统库下的ibdata1、ib_logfile*、auto.cnf（含 server-uuid）、以及所有数据库子目录——漏掉auto.cnf会导致集群节点 UUID 冲突 - 首次启动前删掉新目录下可能残留的
ib_logfile*（除非确定是同版本、同innodb_log_file_size迁移）
软链接适合临时救急或测试环境；真要长期用，改配置+全量复制+校验，才真正可控。最易被忽略的是 auto.cnf 和 SELinux/AppArmor 策略更新——这两处一漏，服务就起不来，还容易查偏方向。
