MySQL表只读错误处理：检查文件系统权限

MySQL报错“Table is read only”的真实原因与系统性修复指南

当MySQL出现“Table is read only”错误时，许多用户会首先检查表设置。然而，问题的根源通常更为底层：该报错的核心是MySQL服务进程失去了对底层表文件的写入能力。问题主要源于四个层面：文件系统权限不足、磁盘被挂载为只读模式、MySQL服务级别的只读配置被意外启用，或操作系统的强制访问控制（如SELinux/AppArmor）拦截了写操作。下文将逐一解析并提供解决方案。

MySQL报错 Table is read only 的真实原因

简而言之，此错误提示存在一定误导性。它并非指表结构或属性被设为只读，而是意味着MySQL进程在尝试写入表对应的物理文件（例如InnoDB的.ibd文件或MyISAM的.MYD文件）时，被操作系统拒绝。因此，排查重点应放在MySQL进程（通常是mysql用户）与这些文件之间的交互上，常见触发点包括文件系统权限、磁盘挂载状态或MySQL内部的只读开关被开启。

检查并修复文件系统级权限和挂载状态

这是最基础且最常出现问题的一环。MySQL进程必须对其数据目录及下属的所有文件拥有读、写、执行权限。同时，数据目录所在的分区绝不能以只读模式挂载。

• 确认目录权限与所有权： 执行命令 ls -ld /var/lib/mysql/yourdb/。需确保目录的属主和属组为mysql:mysql，且权限至少包含drwxr-x---（即所有者拥有全部权限，同组用户拥有读和执行权限）。
• 检查磁盘挂载模式： 运行 mount | grep "$(df . | tail -1 | awk '{print $1}')" 查看当前分区挂载详情。重点检查输出中是否包含ro（read-only）标志。若出现ro，则表明磁盘被挂载为只读。
• 诊断只读挂载的根源： 磁盘变为只读挂载通常有因可循。可能是底层磁盘出现I/O错误（使用dmesg | tail查看内核日志），也可能是文件系统损坏（可使用sudo e2fsck -n /dev/sdXN进行预检），或人为执行了mount -o remount,ro命令。
• 临时修复挂载状态： 仅在确认无硬件故障或文件系统严重错误后，方可尝试临时重新挂载为读写模式：sudo mount -o remount,rw /mount/point。请注意，此为临时手段，必须彻底排查并解决导致只读的根本原因。

确认 MySQL 服务级只读配置未被误启

即使文件系统一切正常，MySQL自身也可能“锁定”写入操作。全局系统变量read_only=ON或super_read_only=ON一旦被设置，将导致所有非超级权限的用户对所有表仅能进行读操作。

• 查询当前只读状态： 登录MySQL后，执行 SELECT @@read_only, @@super_read_only;。正常情况下，两者返回值均应为0（即OFF状态）。
• 检查配置文件： 查看MySQL配置文件（如/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），确认其中没有read_only = 1或super_read_only = 1此类配置行。
• 注意复制场景的干扰： 若当前实例本应为主库，却开启了read_only，需检查是否误配置了复制相关参数。例如，relay_log_recovery=ON参数在某些情况下会导致MySQL启动时自动设置为只读模式。

验证表文件所有权和 SELinux/AppArmor 干扰

在Linux发行版上，尤其是CentOS/RHEL或Ubuntu/Debian，强制访问控制（MAC）系统是一个常被忽略的“隐形守卫”。即使文件权限和MySQL配置均正确，SELinux或AppArmor也可能因安全策略阻止MySQL进程写入文件。

• 针对SELinux（CentOS/RHEL）： 运行 sudo ls -Z /var/lib/mysql/yourdb/yourtable.ibd 查看文件的安全上下文。正确的上下文通常应包含mysqld_db_t类型。若非如此，需修复上下文：
  1. 添加默认上下文规则：sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)"
  2. 应用新规则：sudo restorecon -Rv /var/lib/mysql
• 针对AppArmor（Ubuntu/Debian）： 首先检查MySQL的AppArmor配置文件是否处于活动状态：sudo aa-status | grep mysql。若其正在限制MySQL，可尝试临时禁用以进行问题隔离：
  1. 将配置文件链接至禁用目录：sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
  2. 重新加载AppArmor配置：sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld
  （注意：此仅为诊断步骤，生产环境需谨慎调整策略文件。）
• 重要警告： 切勿使用chown -R root:mysql此类命令粗暴更改整个数据目录的所有权。这可能导致MySQL服务无法启动或拒绝加载表文件，因为MySQL期望数据目录的属主为mysql用户。

最后，有两点经验值得注意：首先，挂载状态和SELinux/AppArmor上下文是最易被忽略的环节，尤其在云主机重装系统或手动迁移数据文件后。其次，在对权限或配置进行任何重大修改前，建议使用mysqld --validate-config命令检查配置文件的合法性，这能有效避免因配置错误导致服务重启失败。系统性排查，方能彻底解决问题。