error 1036 “table is read only” 多因磁盘满或表被强制只读，非权限问题；优先执行 df -h 检查 / 或 /var/lib/mysql 所在分区使用率，再查 inode、read_only 变量及元数据锁。
MySQL 报错 ERROR 1036 (HY000): Table is read only 怎么快速定位
这错误不是权限问题，大概率是磁盘满或表被强制只读。先别急着改权限，df -h 看根分区或 /var/lib/mysql 所在分区——90% 以上情况是 / 或 /var 满了。MySQL 检测到磁盘空间不足时，会自动把所有表设为只读，防止写入失败导致数据损坏。
检查命令顺序建议：
-
df -h | grep -E '(\/$|var|mysql)'—— 看关键挂载点使用率 -
df -i—— 别漏 inode 耗尽（尤其小文件多的环境） -
SHOW VARIABLES LIKE 'read_only';—— 如果返回ON，再查是不是mysqld启动时加了--read-only参数 -
SELECT * FROM information_schema.INNODB_TRX\G—— 长事务没提交也可能让后续 DML 看似卡住，但不会直接报只读
如何确认是不是表被锁死而不是磁盘问题
磁盘空间充足但 INSERT/UPDATE 一直卡住、超时，或者 SHOW PROCESSLIST 里大量线程状态是 Waiting for table metadata lock，说明是元数据锁（MDL）阻塞，不是磁盘问题。
典型场景：
- 对大表执行
ALTER TABLE时，其他查询被阻塞 - 一个事务里执行了
SELECT ... FOR UPDATE但没提交，后续写操作等在那 - 应用连接泄漏，事务长期未关闭，锁一直挂着
查锁最直接的命令：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'PENDING'\G（5.7+）。如果没开 performance_schema，就用 SHOW OPEN TABLES WHERE In_use > 0; 辅助判断哪些表正被强占。
FLUSH TABLES WITH READ LOCK 没释放怎么办
这个命令会让整个实例只读，且不随客户端断开自动释放，常被运维误用后忘记 UNLOCK TABLES。一旦触发，所有写操作立刻失败，错误信息就是 Table is read only。
确认方式很简单：
- 执行
SELECT @@global.read_only;—— 如果是1，基本就是它干的 - 检查 MySQL 错误日志，搜
FLUSH TABLES WITH READ LOCK关键字 - 注意：即使你没手动执行过，某些备份脚本（如老版本
mysqldump --lock-all-tables）也会隐式调用它
解决办法只有登录 MySQL 后执行：UNLOCK TABLES;。别重启 mysqld——重启后锁会自动释放，但可能丢失未刷盘的 binlog 位点，影响主从同步。
为什么删了文件磁盘还是满？rm 不等于空间释放
常见陷阱：发现 /var/lib/mysql 下某个大日志文件（比如 slow.log 或旧 binlog）占空间，rm 掉后 df -h 仍显示 100%。这是因为文件被 mysqld 进程打开着，rm 只是解除了目录项链接，实际 inode 还在占用磁盘块。
验证和清理步骤：
-
lsof +L1—— 查看被删除但仍被进程占用的文件（+L1 表示 link count == 0） - 找到 mysqld 对应的行，记下 PID 和文件描述符（比如
/var/lib/mysql/mysql-slow.log (deleted)） - 安全做法是：先
SET GLOBAL slow_query_log = OFF;，再rm；或者重启 mysqld（生产慎用） - 临时释放空间：用
echo > /proc/<pid>/fd/<fd_num></fd_num></pid>清空句柄内容（仅限日志类可截断文件）
真正释放空间，得让进程主动 close() 或者重启服务。别指望 rm 一劳永逸。
