MySQL报错ERROR 1290 (HY000)本质是服务端启用了只读模式（read_only=ON）、--skip-grant-tables、--read-only、--sql-replica-on或--secure-file-priv等限制性选项，需根据具体错误信息定位原因并修改配置或权限设置。
MySQL服务端开启了只读模式
phpMyAdmin报“只读错误”，本质是 MySQL 服务端返回了 ERROR 1290 (HY000) 或类似提示（如 The MySQL server is running with the --read-only option），说明 mysqld 进程本身被配置为只读。这不是 phpMyAdmin 的限制，而是数据库层面的硬性策略。
常见触发场景：
- 主从架构中，从库默认启用
read_only = ON - 管理员手动执行了
SET GLOBAL read_only = ON - MySQL 配置文件
my.cnf的[mysqld]段写了read_only = 1 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）在只读实例或维护窗口期自动开启该模式
验证方式：在 phpMyAdmin 的 SQL 窗口执行 SELECT @@read_only;，返回 1 即确认开启。
解决建议：
立即学习“PHP免费学习笔记（深入）”；
- 若你有服务器 root 权限且确需写入，临时关闭：执行
SET GLOBAL read_only = OFF;（注意：需 SUPER 权限；重启后失效） - 若配置文件中硬编码了
read_only = 1，需编辑my.cnf删除或注释该行，并重启mysqld - 云数据库用户请检查控制台“实例状态”和“参数设置”，部分平台需在控制台开关“只读实例”或申请“解除只读”工单
当前用户账号被授予了只读权限
即使 MySQL 全局未启用只读，某个具体用户也可能被显式限制为只读。此时执行 INSERT、UPDATE、DROP 等语句会直接报错，典型错误信息含 Access denied 或 command denied，但更隐蔽的是仅对写操作拒绝而查询正常。
检查方法：
- 在 phpMyAdmin 中执行
SELECT CURRENT_USER();确认当前登录身份（格式为'user'@'host'） - 执行
SHOW GRANTS FOR CURRENT_USER;，重点看是否只有SELECT、USAGE权限，缺少INSERT、UPDATE、DELETE、CREATE等
修复路径：
- 用高权限账号（如 root）登录，执行
GRANT INSERT, UPDATE, DELETE ON `db_name`.* TO 'your_user'@'localhost'; FLUSH PRIVILEGES; - 避免直接授
ALL PRIVILEGES，按最小权限原则补充缺失项 - 若使用宝塔等面板，可在【数据库】→【权限管理】里图形化勾选对应权限
phpMyAdmin自身配置启用了只读界面
极少数定制部署或安全加固场景下，phpMyAdmin 的 config.inc.php 可能被手动添加了 $cfg['ReadOnly'] = true;。该配置会让整个 Web 界面禁用所有写操作按钮（如“插入”“执行”“清空”），但更关键的是——它会在提交 SQL 前拦截并拒绝任何非 SELECT、SHOW、EXPLAIN 类语句，直接返回“Access denied for this operation”。
定位方式：
- 打开 phpMyAdmin 安装目录下的
config.inc.php - 搜索
ReadOnly，确认是否存在类似$cfg['ReadOnly'] = true;或$cfg['DisableIS'] = true;（后者也会抑制写操作）
注意点：
- 这个配置不会影响命令行 mysql 客户端，仅作用于 phpMyAdmin Web 界面
- 修改后必须重启 Web 服务器（如 nginx/apache）或至少重载 PHP-FPM 才能生效
- 生产环境不建议全局关闭，可考虑针对特定数据库用
$cfg['Servers'][$i]['DisableIS']细粒度控制
事务或会话级只读设置被意外激活
MySQL 支持会话级只读控制：SET SESSION transaction_read_only = ON;。一旦设置，该连接后续所有写操作都会失败，错误提示可能不明确（如 Can't execute statement in a READ ONLY transaction）。这种设置容易被忽略，因为它不改变全局状态，也不出现在配置文件中。
排查步骤：
- 在出问题的 phpMyAdmin 标签页中，执行
SELECT @@transaction_read_only, @@session.transaction_read_only; - 若返回值为
1，说明当前会话已被设为只读 - 临时恢复：执行
SET SESSION transaction_read_only = OFF;
根因可能包括：
- SQL 文件开头包含该语句但被误保留
- 某次调试时手动执行过，未重连就继续操作
- ORM 或脚本在连接池中复用了带该设置的连接（较少见，但需留意）
这类问题最易被当成“突然故障”，实际只需重连一次或显式关闭即可恢复——但它恰恰最容易被跳过检查。
