MySQL报错 ERROR 3 或 OS error code 28: No space left on device 怎么快速定位
这不是 MySQL 自己爆的错，是操作系统拒绝写入后透出的信号。优先查磁盘，不是查 MySQL 配置。
- 立刻执行
df -h，重点看/var/lib/mysql所在分区（常见是/或/var）是否 100% 满 - 再跑
df -i，确认是不是 inode 耗尽——尤其当小文件极多（比如 binlog 日志碎片、临时表）时容易中招 - 别只盯着
ibdata1或表文件；mysql-bin.*、mysql-relay-bin.*、/tmp下的临时文件、甚至慢查询日志都可能撑爆磁盘
清理 binlog 日志前必须确认的三件事
删 binlog 不是删普通日志，它关系到主从同步和 PITR（基于时间点恢复）。误删会导致从库中断或无法回滚。
- 先用
SHOW MASTER LOGS;看当前活跃日志列表，记下File最后一个文件名（如mysql-bin.000123） - 如果开了主从，必须确认所有从库的
Relay_Master_Log_File（查SHOW SLAVE STATUS\G）没超过你要删的范围 - 生产环境别用
PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00'这种模糊方式；优先用PURGE BINARY LOGS TO 'mysql-bin.000100'，精确到文件名更安全
tmpdir 和 innodb_tmpdir 占满怎么办
大排序、大 join、GROUP BY、CREATE TABLE AS SELECT 都会在临时目录生成巨型文件，且默认不自动清理。
- 查当前设置：
SELECT @@tmpdir, @@innodb_tmpdir;；多数情况指向系统/tmp，而它常是内存挂载（tmpfs），大小受限于 RAM - 临时救急：重启 MySQL 前把
tmpdir改到空间充足的分区，例如tmpdir = /data/mysql-tmp，并确保 MySQL 用户有读写权限 - 长期建议：调低
sort_buffer_size和join_buffer_size（别设成几 G），避免单个查询吃光 tmpdir；对大表操作，加ORDER BY或GROUP BY字段上建索引，减少磁盘临时表生成
哪些日志可以安全关，哪些必须留但要轮转
MySQL 默认不开太多日志，但 DBA 手动开的往往忘了收口。关键不是“全关”，而是“可控”。
- 可关（若无审计/排查需求）：
general_log = OFF（通用日志）、slow_query_log = OFF（除非正在定位慢 SQL） - 必留但需轮转：
log_error错误日志——用 logrotate 配置按天切割 + 压缩 + 保留 7 天，避免单个文件超 GB - 危险操作：
log_bin = OFF不能随便关，否则主从、GTID、闪回都失效；如真要关，务必提前停写、备份、评估 RPO
最常被忽略的是 relay log 清理策略。从库上 relay_log_purge = ON 是默认值，但如果从库延迟高、又手动停过 SQL_THREAD，relay log 可能堆积数 GB 且不会自动删——这时得手工 RESET SLAVE（注意：会清空复制坐标，仅限确定不再需要该从库时用）。
