MySQL启动失败主因是权限与SELinux限制，需正确赋权、配置SELinux上下文、同步修改my.cnf及systemd服务参数，并仅复制数据库子目录而非InnoDB系统文件，最后交叉验证datadir真实路径。

MySQL 启动失败报错 Can't find file: './mysql/plugin.frm' 或数据目录无权限

在Linux系统中修改MySQL默认数据存储目录后，服务启动失败是常见问题。错误信息通常表现为无法定位系统表文件或提示权限被拒绝。其根本原因在于MySQL服务进程无法正常访问新的数据路径。MySQL服务默认以mysql系统用户身份运行，该用户必须对新目录拥有完整的读、写和执行权限。此外，如果服务器启用了SELinux安全模块（例如CentOS或RHEL 7及以上版本），它还会严格限制对非标准路径的访问，直接阻止MySQL进程读写数据。

要彻底解决此问题，请按照以下关键步骤逐一排查：

• 确认磁盘挂载状态：首先确保目标数据目录所在的磁盘分区已正确挂载。检查挂载参数，确保未使用noexec（禁止执行）、nosuid（忽略SUID权限）或nodev（忽略设备文件）等限制性选项。可以通过查看/proc/mounts文件或执行mount | grep /data命令来验证。
• 递归修改目录所有权：使用chown -R mysql:mysql /data/mysql命令，将新数据目录及其内部所有文件和子目录的所有者与所属组均设置为mysql。仅修改目录本身权限而忽略内部内容，将导致MySQL无法访问具体数据文件。
• 配置SELinux安全上下文：对于启用SELinux的系统，必须为新目录赋予正确的安全标签。执行命令semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?"添加永久规则，然后运行restorecon -Rv /data/mysql立即应用更改，使目录获得MySQL数据库文件的合法访问身份。
• 避免使用chmod 777：为图方便而赋予目录全局可读写权限是严重的安全隐患。MySQL出于安全考虑，会拒绝启动并记录类似World-writable config file is insecure的警告日志。

修改 datadir 的三个关键位置：配置、服务、初始化目录结构

许多用户误以为只需在my.cnf配置文件中更改datadir参数即可完成迁移。实际上，这是一个常见误区。MySQL启动过程会综合校验socket文件、pid文件路径与实际数据文件位置的一致性。任何环节的配置缺失或不匹配，都会导致服务启动失败。

因此，完整的修改必须同步以下三个层面：

• 全面更新配置文件：编辑/etc/my.cnf（或/etc/mysql/my.cnf），在[mysqld]配置段中，不仅需要设置datadir=/data/mysql，还应显式指定socket=/data/mysql/mysql.sock和pid-file=/data/mysql/mysqld.pid，以避免因路径依赖而产生的潜在冲突。
• 检查并覆盖systemd服务参数：运行systemctl cat mysqld命令查看服务单元定义。如果发现类似Environment="MYSQLD_OPTS=--datadir=/var/lib/mysql"的硬编码环境变量，说明systemd服务层覆盖了配置文件中的设置。此时，需要通过创建/etc/systemd/system/mysqld.service.d/override.conf文件来覆盖此变量，或直接修改服务单元文件。
• 遵循正确的迁移与初始化流程：操作前务必使用systemctl stop mysqld停止MySQL服务。完成数据文件迁移后，必须在新的datadir下初始化系统数据库。对于MySQL 5.7及更早版本，使用mysql_install_db --user=mysql --datadir=/data/mysql命令；对于MySQL 8.0及以上版本，则应使用mysqld --initialize --user=mysql --datadir=/data/mysql。

从 /var/lib/mysql 迁移数据时，ibdata1 和 ib_logfile* 不能直接复制

迁移MySQL数据时，直接复制整个/var/lib/mysql目录是最危险的操作之一。核心的InnoDB系统文件，如ibdata1（共享表空间文件）和ib_logfile0/1（重做日志文件），其内部结构、文件路径和校验信息与初始化时的datadir深度绑定。将这些文件强行复制到新位置，极有可能导致MySQL启动时报InnoDB: Database page corruption on disk（数据库页面损坏）错误，甚至引发服务崩溃。

安全的数据库迁移应遵循以下策略：

• 选择性复制数据库目录：停止MySQL服务后，仅复制各个独立的数据库子目录（例如mysql/、performance_schema/以及您的业务数据库文件夹）。若需保留二进制日志用于主从复制，mysql-bin.*和mysql-relay-bin.*系列文件也可一并复制。
• 让InnoDB引擎重建系统文件：将ibdata1、ib_logfile0、ib_logfile1等文件留在原目录或直接删除。当MySQL在新目录启动时，InnoDB存储引擎会根据my.cnf中的innodb_data_file_path和innodb_log_file_size参数，自动在新数据目录下重新生成这些核心文件。
• 处理独立表空间文件：如果原数据库启用了innodb_file_per_table=ON设置，那么每个InnoDB表对应的.ibd文件是可以安全复制的。但在操作前，建议通过查询information_schema.INNODB_SYS_TABLES（或相应版本的系统表）来确认表状态正常，避免迁移已损坏的文件。

验证新 datadir 是否真正生效：别只信 SELECT @@datadir

修改配置后，仅通过SELECT @@datadir;命令看到新路径就认为成功，这可能是一个重大陷阱。该命令仅返回配置文件中的参数值，而非MySQL运行时实际使用的数据目录路径。如果因权限不足、SELinux拦截或路径不存在等问题，MySQL可能会静默回退到编译时的默认路径（如/var/lib/mysql），而进程看似仍在运行，造成修改成功的假象。

为确保修改彻底生效，必须进行多维度交叉验证：

• 多角度查询运行时路径：连接MySQL后，除了执行SHOW VARIABLES LIKE 'datadir';，在MySQL 8.0及以上版本中，还可以尝试运行SELECT FILE_PATH FROM performance_schema.data_locks LIMIT 1;，从性能模式的数据锁信息中探查实际的数据文件路径。
• 检查进程打开的文件描述符：这是最可靠的验证方法之一。首先使用lsof -i :3306 | grep mysql找到mysqld进程的PID，然后执行lsof -p | grep mysql | head -5，观察列出的文件（如.frm、.ibd）是否确实来源于您设置的新数据目录。
• 执行实际写入测试：在新启动的MySQL中创建一个测试数据库和表，然后立即到文件系统查看：ls -l /data/mysql/your_db/。如果能在此目录下看到新生成的.frm和.ibd文件，且其时间戳为最新，则证明数据目录修改已完全生效。

最后需要特别警惕，SELinux上下文重置失败和systemd环境变量覆盖是两类最为隐蔽的问题。它们通常不会在MySQL错误日志中留下清晰记录，只会导致服务“静默”地继续使用旧路径。在排查MySQL数据目录迁移故障时，务必对这两个环节保持高度关注。