MySQL从库启用read_only=ON后，所有非SUPER权限用户的写操作均被拒绝，报ERROR 1290，该限制独立于用户权限配置，phpMyAdmin无法绕过或提示该状态。
因为 MySQL 从库默认启用 read_only=ON，且该设置优先级高于用户权限——即使你给账号授了 UPDATE 或 INSERT，执行时仍会直接报错“Table ‘xxx’ is read only”。
read_only 是全局只读开关，不是权限控制项
很多人误以为只要在 phpMyAdmin 里给用户勾了“全局 INSERT/UPDATE”，就能在从库上写数据。其实 read_only 是 MySQL 实例级的只读锁，它在服务启动时或运行中由 DBA 主动开启（常见于主从架构），一旦启用，所有非 SUPER 权限用户的所有写操作都会被拒绝，连 CREATE TEMPORARY TABLE 都不行。
这个限制和用户权限表（mysql.user、mysql.db）完全无关，所以你在 phpMyAdmin 的“编辑权限”页面怎么改，都无效。
- 检查当前状态：
SELECT @@read_only;返回1即表示已启用 - 临时关闭（仅限调试，不推荐生产环境）：
SET GLOBAL read_only = OFF;（需 SUPER 权限） - 永久关闭需修改
my.cnf中的read_only = OFF并重启 mysqld
为什么 phpMyAdmin 不提示 read_only 状态？
phpMyAdmin 本身不会主动检测或高亮显示 read_only 状态，它只负责转发 SQL 请求。当你在从库界面点“插入”或执行 UPDATE 时，MySQL 内核在解析阶段就拦截并返回错误，比如：
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement
这个错误不是权限不足（ERROR 1044 或 ERROR 1142），而是服务配置级拒绝——所以翻遍 phpMyAdmin 的权限设置页也找不到对应开关。
- 不要尝试用 phpMyAdmin 的“用户权限”页面去“绕过”只读限制
- 不要在从库上手动建表或改结构，这类操作会破坏主从一致性
- 如果必须写，应确认是否真要写从库（通常不该），还是该切回主库连接
从库写操作失败的典型现象
不是所有写操作都报一样的错，但根源都是 read_only。常见表现有：
-
INSERT INTO ...报ERROR 1290 -
TRUNCATE TABLE报ERROR 1290（注意：它比DELETE更重，会被read_only明确拦截） - phpMyAdmin 点“清空表”按钮后无响应或弹出空白错误框（底层实际触发了
TRUNCATE） - 执行
ALTER TABLE时卡住或报错，即使你有ALTER权限
这些都不是 phpMyAdmin 的 bug，是它忠实地把请求交给了只读实例。
真正关键的判断点在于：你连的是主库还是从库？别只看 phpMyAdmin 左上角显示的服务器名，要用 SELECT @@server_id; 和 SHOW SLAVE STATUS\G（从库才有输出）交叉验证。很多运维习惯把主从都部署在同一台机器、用不同端口，但 phpMyAdmin 连接配置没区分清楚，就会误操作。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
