mysql日志清理的核心目的是释放磁盘空间，保障数据库稳定运行。1. 二进制日志清理可通过手动执行purge binary logs命令或配置expire_logs_days和max_binlog_size实现自动清理；2. 慢查询日志可手动删除或使用logrotate工具进行轮转处理；3. 日志格式优化可通过设置binlog_format为statement或mixed减少日志量；4. 分析慢查询日志推荐使用mysqldumpslow工具并结合explain分析sql执行计划；5. 清理日志后若性能下降需检查innodb的ibdata1文件、索引碎片及统计信息，分别通过数据导出重建、optimize table和analyze table解决。操作时应注意主从复制同步、备份日志文件及选择业务低峰期执行关键维护任务。
MySQL日志清理，说白了就是释放磁盘空间，保证数据库正常运行。二进制日志记录了所有数据库更改，慢查询日志则记录了执行时间较长的SQL语句。不定期清理，硬盘迟早爆炸。
解决方案
二进制日志清理:
方法一：手动清理
登录MySQL，执行
PURGE BINARY LOGS BEFORE 'YYYY-MM-DD HH:MM:SS';或者
PURGE BINARY LOGS TO 'log_name';。前者是删除指定日期之前的所有日志，后者是删除指定日志文件之前的日志。
log_name可以通过
SHOW BINARY LOGS;命令查看。
例如：
PURGE BINARY LOGS BEFORE '2023-12-01 00:00:00';
方法二：自动清理 (推荐)
修改MySQL配置文件 (my.cnf 或 my.ini)。 添加或修改以下参数：
expire_logs_days = 7 # 保留7天的日志 max_binlog_size = 100M # 每个日志文件最大100MB
重启MySQL服务使配置生效。
expire_logs_days参数指定了日志保留天数，MySQL会自动删除超过这个天数的日志。
max_binlog_size参数指定了每个二进制日志文件的最大大小，当日志文件达到这个大小后，MySQL会自动创建一个新的日志文件。
需要注意的是，如果你的MySQL主从复制依赖二进制日志，清理之前一定要确保从服务器已经同步了这些日志，否则会导致数据不一致。
慢查询日志清理:
方法一：手动清理
直接删除慢查询日志文件。 慢查询日志文件的位置可以通过
SHOW VARIABLES LIKE 'slow_query_log_file';命令查看。 删除之前，最好备份一下，万一以后需要分析呢？
方法二：日志轮转 (logrotate)
使用Linux自带的
logrotate工具进行日志轮转。 创建一个
/etc/logrotate.d/mysql-slow文件，内容如下：
/path/to/your/slow-query.log { # 替换成你的慢查询日志路径
daily
rotate 7
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/bin/mysqladmin -u root -p'your_password' flush-logs # 替换成你的MySQL root密码
endscript
}这个配置表示每天轮转一次慢查询日志，保留7天的日志，压缩旧的日志文件。
postrotate部分会在日志轮转之后执行，这里使用
mysqladmin flush-logs命令来刷新MySQL日志，让MySQL重新生成一个新的慢查询日志文件。 注意替换
/path/to/your/slow-query.log和
your_password。
logrotate的配置非常灵活，可以根据实际需求进行调整。
MySQL二进制日志占用空间过大怎么办？如何优化二进制日志设置？
检查binlog_format
:
binlog_format参数决定了二进制日志的格式。 有三种格式：
STATEMENT,
ROW,
MIXED。
ROW格式会记录每一行数据的更改，日志量最大。 如果对数据一致性要求不高，可以考虑使用
STATEMENT或
MIXED格式。 执行
SHOW GLOBAL VARIABLES LIKE 'binlog_format';查看当前格式。 修改配置文件修改
binlog_format的值。
减少不必要的日志记录: 有些操作是不需要记录到二进制日志的，例如只读操作。 可以通过设置
sql_log_bin = 0;来禁止当前会话记录二进制日志。 但是要注意，这个设置只对当前会话有效。
合理设置max_binlog_size
和expire_logs_days
:
max_binlog_size参数控制单个二进制日志文件的大小，
expire_logs_days参数控制日志保留天数。 根据实际情况调整这两个参数，可以在保证数据安全的前提下，减少日志占用空间。
如何分析MySQL慢查询日志？ 使用mysqldumpslow工具
mysqldumpslow是MySQL自带的慢查询日志分析工具。 它可以统计慢查询日志中出现频率最高的SQL语句，并按照执行时间、锁定时间、返回记录数等指标进行排序。
使用方法：
mysqldumpslow -s t -t 10 /path/to/your/slow-query.log # 按照执行时间排序，显示前10条
参数说明：
-s: 排序方式，常用的有
t(执行时间),
l(锁定时间),
r(返回记录数),
c(出现次数)。
-t: 显示的条数。
mysqldumpslow工具可以帮助你快速找到执行效率低的SQL语句，然后进行优化。 也可以结合
EXPLAIN命令分析SQL语句的执行计划，找出瓶颈所在。
MySQL日志清理后，数据库性能反而下降了？ 可能的原因及解决办法
清理日志本身不会直接导致数据库性能下降。 但是，如果清理日志的方式不正确，或者清理之后没有进行相应的维护操作，可能会间接影响数据库性能。
InnoDB引擎的ibdata1
文件: 如果你的MySQL使用了InnoDB引擎，所有的数据和索引都存储在
ibdata1文件中。 即使你删除了数据，
ibdata1文件的大小也不会自动缩小。 这会导致数据库扫描的数据量增加，从而影响性能。
解决办法： 需要使用
mysqldump工具导出数据，然后删除
ibdata1文件，再重新导入数据。 这个过程比较复杂，需要谨慎操作。 也可以考虑使用
innodb_file_per_table参数，将每个表的数据和索引存储在单独的文件中，这样删除数据后，磁盘空间就可以被释放。
索引碎片: 频繁的插入、更新、删除操作会导致索引碎片。 索引碎片会降低查询效率。
解决办法： 使用
OPTIMIZE TABLE命令对表进行优化。 这个命令会重建索引，消除碎片。 但是，
OPTIMIZE TABLE命令会锁定表，所以需要在业务低峰期执行。
统计信息不准确: MySQL使用统计信息来优化查询计划。 如果统计信息不准确，可能会导致MySQL选择错误的执行计划，从而影响性能。
解决办法： 使用
ANALYZE TABLE命令更新表的统计信息。 这个命令会扫描表的数据，计算统计信息。 同样，
ANALYZE TABLE命令也需要在业务低峰期执行。
总之，清理MySQL日志是一个重要的维护任务，但是要注意清理的方式和清理后的维护工作。 只有这样才能保证数据库的稳定运行和高性能。
