最常见根源是全局只读模式启用：执行SELECT @@read_only;若返回1，说明read_only=ON已生效，需检查配置文件及主从角色是否误配。
确认是否全局只读模式被启用
错误 ERROR 1036 (HY000): Table 'xxx' is read only 最常见却最容易被忽略的根源，是 MySQL 实例启用了全局只读：read_only=ON。这会阻止所有非 SUPER 权限用户对非临时表的写入，哪怕表本身和文件系统完全正常。
执行以下命令快速验证：
SELECT @@read_only;
如果返回 1，说明已启用。此时需检查：
-
/etc/my.cnf或/etc/mysql/mariadb.conf.d/50-server.cnf中是否含有read_only=1或read_only=ON - 主从架构中，从库默认应设为
read_only=ON；若误在主库启用，或从库被人工切为主后未关闭该配置，就会触发此报错 - 某些高可用工具（如 MHA、Orchestrator）会在故障转移后自动设置
read_only=ON，但未清理残留配置
临时关闭（仅用于验证）可执行：SET GLOBAL read_only = OFF;，但务必确认操作上下文——生产主库禁用前必须确保无意外写入风险。
检查表文件权限与属主
MySQL 进程（通常是 mysql 用户）必须对数据目录下对应表的物理文件拥有读写权限。常见于手动迁移、恢复备份或挂载外部存储后忘记修正权限。
以表 test.users 为例，其文件通常位于：/var/lib/mysql/test/users.ibd（InnoDB）或 /var/lib/mysql/test/users.MYD（MyISAM）。执行：
ls -l /var/lib/mysql/test/users.*
关键看三件事：
- 属主是否为
mysql:mysql（或运行 mysqld 的实际用户） - 文件权限是否包含写位（如
-rw-rw----合理，-r--r--r--就不行） - 整个路径（
/var/lib/mysql/test/及上级）的执行位（x）是否开启——缺少会导致“无法进入目录”，表现为只读错觉
修复命令示例：chown -R mysql:mysql /var/lib/mysql/test/ && chmod -R 660 /var/lib/mysql/test/*.ibd（注意：不要盲目 chmod 777，有安全风险）。
验证存储引擎是否支持写入且状态正常
某些引擎在异常状态下会自动置为只读，尤其是 MyISAM 表损坏时，MySQL 会将其标记为只读以防进一步写入；InnoDB 表若因崩溃未完成恢复，也可能暂时拒绝写入。
先查引擎类型：
SHOW CREATE TABLE xxx\G
然后分情况处理：
- 如果是
MyISAM：运行REPAIR TABLE xxx;。若提示Table is marked as crashed或failed to repair，说明文件已损坏，需从备份恢复 - 如果是
InnoDB：检查错误日志（/var/log/mysql/error.log）中是否有innodb_force_recovery相关提示或corruption字样；若怀疑损坏，优先尝试mysqldump导出再重建，而非直接修复 - 避免使用
MEMORY引擎存关键业务表——它不持久化，实例重启即丢失，且某些版本在内存不足时行为异常，可能被降级为只读
特别注意：ARCHIVE 和 FEDERATED 引擎原生不支持 UPDATE/DELETE，试图执行会直接报 1036，不是故障而是设计如此。
排查用户权限与 SQL 模式干扰
即使表和实例都正常，用户权限不足或 SQL 模式限制也会导致写操作失败并返回只读错。这不是真正的只读，而是权限/语法层面的拦截。
检查当前用户权限：
SHOW GRANTS FOR CURRENT_USER;
重点确认是否包含目标库表的 INSERT、UPDATE、DELETE 权限（而不仅是 SELECT）。常见陷阱：
- 权限授予的是
'user'@'localhost'，但连接来自远程，实际匹配的是'user'@'%'——后者可能没授写权限 - 使用了
SQL_MODE=STRICT_TRANS_TABLES等严格模式，某条INSERT因字段超长或空值被拒绝，部分客户端错误包装成只读提示 - 触发器中隐含写操作，但触发器定义者权限不足，间接导致主语句失败
临时绕过模式限制测试（仅调试）：SET SESSION sql_mode = '';，再重试写操作。若成功，则问题出在数据合法性或模式约束上，而非表只读本身。
真正棘手的 case 往往是多个因素叠加：比如从库开启了 read_only，同时表文件权限又被误改，错误日志里还混着 InnoDB 恢复警告。别急着逐个试，先用 SELECT @@read_only 和 SHOW CREATE TABLE 锁定最外层开关，再一层层剥开。文件权限和引擎状态这类底层问题，一旦忽略，修完配置重启服务也照样报错。
