90%以上根分区100%的MySQL服务器问题源于mysql-bin.*文件未自动清理，主从延迟或配置失效致日志无限堆积；需先用df、du定位，再查binlog_expire_logs_seconds是否生效，PURGE前必须核对主从安全水位线并检查大事务占用句柄。
直接结论：90%以上根分区100%的MySQL服务器，问题就出在mysql-bin.*文件没被自动清理，且主从延迟或配置失效导致日志无限堆积。
查证Binlog是否真在撑爆磁盘
别猜，先定位。很多“磁盘满”其实是/var/lib/mysql下mysql-bin.*文件占了上百GB，但df -h只显示/分区100%，容易误判为系统文件问题。
- 运行
df -Th确认哪个挂载点满（大概率是/或/var） - 接着用
du -sh /var/lib/mysql/mysql-bin.* | sort -hr | head -20看前20个binlog文件大小 - 再执行
mysql -uroot -p -e "SHOW BINARY LOGS;"，对比File_size列总和与du结果是否吻合 - 如果
du显示mysql-bin.0000xx单个就超1GB、总数超50GB，基本坐实问题
检查Binlog自动清理是否真正生效
MySQL默认expire_logs_days = 0，等于永不清除——这不是bug，是设计。8.0+还废弃了这个参数，只认binlog_expire_logs_seconds，设了expire_logs_days反而可能干扰。
- 进MySQL执行：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';，若返回0或空值，说明自动清理关闭 - 同时查
SHOW VARIABLES LIKE 'expire_logs_days';，若非0，必须立刻SET GLOBAL expire_logs_days = 0;清掉，避免冲突 - 注意：仅
SET GLOBAL是临时的，重启即失效；必须编辑my.cnf（如宝塔路径是/www/server/mysql/etc/my.cnf），在[mysqld]段追加：
binlog_expire_logs_seconds = 604800 expire_logs_days = 0
然后systemctl restart mysqld，重启后立刻验证变量值是否已更新。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
PURGE前必须核对主从安全水位线
直接PURGE MASTER LOGS TO 'mysql-bin.000036';可能断主从——删掉从库还没读的日志，Slave_IO_Running立刻变No，报错Got fatal error 1236。
- 主库上执行
SHOW MASTER STATUS;，记下当前File（比如mysql-bin.000042） - 所有从库连上去执行
SHOW SLAVE STATUS\G，重点看Relay_Master_Log_File和Exec_Master_Log_Pos - 找出所有从库中
Relay_Master_Log_File最旧的那个（比如mysql-bin.000035），这就是安全下限：你最多只能PURGE TO 'mysql-bin.000036'; - 执行命令：
PURGE BINARY LOGS TO 'mysql-bin.000036';，清理后SHOW BINARY LOGS;确认数量下降
清理后空间不释放？大概率是文件句柄未关闭
Linux下即使PURGE成功，如果还有进程（比如慢查询、长事务、未关闭连接）正持有旧binlog的文件句柄，磁盘空间就不会真正释放。
- 运行
lsof +L1，看是否有deleted状态的mysql-bin.*文件被进程占用 - 若有，对应PID通常是MySQL自身（
mysqld），此时需确认是否有大事务卡住：SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5; - 紧急情况下可杀掉长期运行事务：
KILL [trx_mysql_thread_id];，但务必先确认业务影响 - 更稳妥做法是等事务自然结束，或重启MySQL（生产环境慎用）
真正的难点不在命令怎么写，而在于你得同时盯住主库位置、所有从库同步点、以及有没有隐藏的大事务死锁着句柄——三者缺一，清理就白做。
