确认是否真只读：执行mount | grep " / "，若输出含(ro,relatime)等字样，说明根分区被内核强制设为只读；此时需查dmesg -T | tail -50定位EXT4/ATA/I/O错误，而非修改MySQL配置或重启服务。
MySQL 无法启动并报 Read-only，90% 不是 MySQL 自己的问题，而是底层文件系统被内核强制设为只读（ro）——直接改 MySQL 配置或重启服务没用，得先查 mount 和 dmesg。
怎么确认是不是真只读？看 mount 输出有没有 ro
执行这行命令：mount | grep " / "。如果输出里带 (ro,relatime) 或类似字样，说明根分区已被挂载为只读。这不是宝塔或 MySQL 的配置问题，是 Linux 内核主动降级保护的结果。别急着进宝塔点“重启 MySQL”，此时连 /www/server/data 目录都写不了，MySQL 进程根本起不来。
- 若显示
rw，但 MySQL 仍报只读，可能是read_only=ON变量开启，或目录权限/SELinux 干预 - 若显示
ro，下一步必须查dmesg -T | tail -50，重点找EXT4-fs error、ata.*error、I/O error—— 这些才是根因 - 云服务器（如阿里云、腾讯云）还要检查控制台是否触发了云盘只读保护（比如快照异常中止）
临时恢复写入：用 mount -o remount,rw / 要谨慎
如果 dmesg 没报硬件错误，只是上次异常断电导致内核保守策略启用，可以尝试重挂载：mount -o remount,rw /。执行后立刻 touch /test && rm /test 验证是否真可写。
- 成功后立即进宝塔重启 MySQL，大概率能起来——但这只是临时缓解，不是修复
- 失败则说明文件系统有残留错误，
e2fsck必须跑，且不能在已挂载的根分区上直接运行 - 某些 SSD/NVMe 固件有 bug，会反复触发
errors=remount-ro，升级固件比调参数更治本
MySQL 启动后还提示 Table is read only？检查三个地方
即使文件系统已恢复读写，MySQL 表仍可能表现为只读，原因分散在服务层、权限层和配置层：
- 执行
mysql -u root -p -e "SELECT @@read_only, @@super_read_only;"，若返回1，说明 MySQL 自身启用了只读模式，需在配置文件中注释或设为read_only = 0 - 用
ls -ld /www/server/data确认目录属主是mysql:mysql，权限至少为drwxr-x---；子目录和文件也要对应（如chown -R mysql:mysql /www/server/data） - CentOS/RHEL 默认开 SELinux，
setsebool -P mysqld_disable_trans 1或临时setenforce 0测试是否拦截写入
/etc/fstab 里的 errors=remount-ro 是隐形定时炸弹
这个选项是 ext4 默认行为：只要文件系统报一次错，内核就自动 remount -o ro。哪怕你用 e2fsck 修好了，只要 /etc/fstab 还留着它，下次出错还会重复。
- 打开
/etc/fstab，找到根分区那一行（通常含/dev/vda1或UUID=...），检查第 4 列（options）是否含errors=remount-ro - 不建议删掉，更稳妥的是保留它，但配合监控：加个定时任务
journalctl -k --since "1 hour ago" | grep -i "ext4\|error" - 若坚持要改，可临时换成
errors=continue，但风险是错误累积可能损坏数据
真正麻烦的从来不是 mount -o remount,rw 这一行命令，而是 dmesg 里那几行 I/O 错误——它意味着磁盘可能正在失效，而你还在忙着改 MySQL 配置。
