返回

数据库表只读(Table is read only)问题全解与修复指南

mysql

数据库表只读 (Table is 'read only') 问题全解

最近操作数据库，执行 update 语句时碰到了一个错误：1036 - Table 'data' is read only。表变成只读的了，改不了数据，这可咋整？ 别急，这篇文章就来好好聊聊这个问题，给你掰开了揉碎了讲。

一、问题根源在哪？

出现 "Table is read only" 的错误，原因可能有很多。下面我给你捋一捋：

  1. 文件系统权限问题: 数据库文件 (比如 .frm, .MYD, .MYI 文件) 所在目录或文件本身，权限设置成了只读，数据库用户没有写入权限。虽然你提到/var/db/mysql的权限是777，但这不代表表文件自身的权限也是777。

  2. 磁盘空间不足： 听起来可能有点不沾边，但确实是个常见原因。磁盘满了，数据库当然写不进东西。

  3. 数据库服务器配置: MySQL 服务器配置了 read_only 参数为 ON。这种情况，整个服务器都是只读的。

  4. 表锁: 其他程序或者会话占用了表锁，导致当前会话无法修改。

  5. 存储引擎问题 (MyISAM): 如果你用的存储引擎是 MyISAM，表可能损坏。MyISAM 对并发控制支持比较弱，容易在异常断电或崩溃时出现问题。

  6. 使用了只读复制 : 在主从复制架构里，从服务器通常设置为只读模式，不允许写入操作.

  7. 触发器或存储过程: 有可能存在一些在你不知道的角落触发的设定，这些设定修改了表的只读属性.

  8. 最大连接数 : 达到设置的最大数据库连接数值,也会阻止继续写入.

二、逐个击破！解决只读问题

知道了原因，接下来就对症下药。下面给出具体的解决办法：

1. 检查和修复文件系统权限

即使/var/db/mysql权限设置为777，你也应该仔细检查相关数据库目录和数据文件的权限. 你可以通过组合find命令找到具体对应的只读文件:

查看数据库目录位置

首先，通过sql命令来查看

SHOW VARIABLES LIKE 'datadir';
找出特定数据表的对应文件:

假设 datadir 的值是 /var/lib/mysql/，而你要操作的数据库名是 your_database，表名是 your_table，则运行如下命令:

find /var/lib/mysql/your_database/ -name "your_table.*" -type f ! -perm /u+w

find 指令详解:

  • /var/lib/mysql/your_database/: 你的表所在的数据库目录。
  • -name "your_table.*": 查找跟你的表相关的文件 (各种扩展名)。
  • -type f: 查找普通文件.
  • ! -perm /u+w: 反选出没有用户写权限的文件。

如果上述指令返回任何内容，代表那些文件可能是只读状态，你可以修正它. 使用chmod修改权限,举例来说,如果上面查询返回了文件/var/lib/mysql/your_database/your_table.MYD, 并且当前用户组可以执行读写,使用下述指令:

sudo chmod 660 /var/lib/mysql/your_database/your_table.MYD

注意： 文件权限的设置要根据实际情况来定，660 (所有者和组用户读写) 通常比较安全。777 权限太开放了，容易出安全问题！

2. 检查磁盘空间

简单粗暴，直接用 df 命令看看：

df -h

看下数据库所在分区是不是满了 (Use% 接近 100%)。如果满了，赶紧清理空间！

3. 检查 MySQL 配置 (read_only)

用这个 SQL 语句查一下：

SHOW VARIABLES LIKE 'read_only';

如果 Value 是 ON，说明整个服务器是只读的。如果你有权限改，可以用：

SET GLOBAL read_only = OFF;

注意： SET GLOBAL 修改的是全局设置，重启 MySQL 后会失效。想永久生效，要修改 MySQL 配置文件 (通常是 my.cnf 或 my.ini)，在 [mysqld] 下面加上 read_only=0，然后重启 MySQL 服务。

4. 检查和释放表锁

看看是不是有锁表的情况：

SHOW OPEN TABLES WHERE In_use > 0;

这条语句能显示当前被锁住的表。如果你的表在里面，可能就需要找到占用锁的进程，然后把它 kill 掉。也可以使用:

SHOW PROCESSLIST;

来显示所有的mysql连接进程.

查到进程 ID (Id 列) 后，用：

KILL process_id;

来结束进程。不过, KILL 进程有风险，小心误杀！最好先搞清楚这个进程在干嘛。

5. 修复 MyISAM 表 (如果适用)

如果你确定表的存储引擎是 MyISAM，而且怀疑表损坏了，可以用 REPAIR TABLE 语句来修复：

REPAIR TABLE your_table_name;

如果 REPAIR TABLE 效果不好，可以试试 myisamchk 工具（在 MySQL 命令行外面用）：

myisamchk -r /path/to/your/table_name.MYI

注意： 使用 myisamchk 之前，最好先停止 MySQL 服务，并备份数据！myisamchk 直接操作数据文件，有一定风险。
建议： MyISAM 引擎现在不太推荐用了。如果可以，考虑换成 InnoDB 引擎，它更稳定，对并发支持也更好。

6. 确认是否为只读复制的从服务器

确认当前数据库是否为从服务器：

SHOW SLAVE STATUS\G

如果你看到了类似于Slave_IO_Running: Yes和Slave_SQL_Running: Yes的输出，并且Read_Only标志为ON，那么你正在一个只读的从服务器上。这种情况下你需要切换至主服务器进行写入.

7.审查触发器(Trigger) 与存储过程(Procedure)

  • 查看触发器
    SHOW TRIGGERS;

逐一审查与目标表有关的触发器，使用SHOW CREATE TRIGGER trigger_name;检查定义。

  • 查看存储过程
    SHOW PROCEDURE STATUS WHERE db = 'your_database_name';

然后根据名称使用SHOW CREATE PROCEDURE procedure_name进行具体检查

关注代码中是否SET了表的read_only属性相关的语句。

8. 审查最大连接数

用这个sql语句查询最大连接配置：

show variables like '%max_connections%';

然后查看当前有多少连接:

show status like 'Threads_connected';

比较两项数据大小, 考虑提升最大连接数量。

进阶技巧和安全建议

  • 使用事务： 对于重要的更新操作，尽量用事务包裹起来。这样即使出错，也可以回滚，避免数据不一致。

  • 定期备份： 数据库备份是救命稻草！养成定期备份的好习惯。

  • 监控数据库： 用一些监控工具 (比如 Prometheus, Grafana) 来实时监控数据库的状态，有问题早发现早解决。

  • 最小权限原则: 不要给数据库账号过高的权限. 只在需要的场合授予UPDATE, INSERT或DELETE的权限, 防范潜在安全风险.

这些解决步骤如果都搞过, 数据库表只读问题总能解决. 希望这个分析能帮你扫除数据库应用的拦路虎！