“Write error at offset”本质是操作系统I/O失败，90%以上由磁盘空间耗尽（errno 28）、文件系统只读或权限/SELinux限制导致，需结合错误日志前后的文件路径、dmesg及df -i等综合诊断。
“Write error at offset”不是MySQL原生错误，而是底层I/O失败后由操作系统抛出的通用提示，本质是MySQL在写入文件（如ibdata、ib_logfile、.ibd或临时文件）时，调用pwrite()或write()系统调用返回了错误。
为什么offset位置会写失败？常见原因就三类
这个错误本身不带上下文，必须结合MySQL错误日志前后的完整信息判断。实际排查中，90%以上都落在下面这三种情况：
- 磁盘空间耗尽：
perror 28显示No space left on device—— 即使df -h看起来还有空间，也可能是inode耗尽、LVM快照满、或XFS预留空间占满 - 文件系统只读：
mount输出含ro，或因ext4 journal损坏、XFS元数据异常被内核自动设为只读；此时mysqld进程仍运行，但任何写操作都会在指定offset处失败 - 权限或SELinux限制：MySQL用户对数据目录（如
/var/lib/mysql）或tmpdir路径无w+权限；SELinux策略拦截mysqld_t对mysql_db_t文件的write访问，ausearch -m avc -ts recent可确认
innodb_flush_log_at_trx_commit=0会触发这个错误吗？
不会直接触发，但会掩盖问题。该参数仅控制redo log刷盘频率，不影响数据文件本身的写入逻辑。不过当它设为0时，MySQL更依赖操作系统缓存，一旦OS层I/O卡住（比如磁盘假死），后续所有写请求都会在offset处阻塞并超时失败。所以看到大量Write error at offset伴随高iowait，优先查磁盘健康度而非MySQL配置。
如何快速定位具体是哪个文件出问题？
MySQL错误日志里紧挨着该错误的上一行，通常会包含文件路径。例如：
2026-06-03T02:15:22.883123Z 0 [ERROR] InnoDB: Write error at offset 1048576, file ./ibdata1
这时重点检查：
-
ls -lh /var/lib/mysql/ibdata1看文件是否异常大或为0字节 -
strace -p $(pgrep mysqld) -e write,pwrite捕获实时写入调用（需在问题复现时运行） -
dmesg -T | tail -20查内核是否报EXT4-fs error或XFS: bad block
真正棘手的是那些不报具体文件名、只显示offset的场景——这往往意味着InnoDB页校验失败后主动abort，此时必须结合innodb_force_recovery和mysqlcheck做页级诊断，而不是盲目调参数。
