快速查看日志文件大小
使用操作系统命令快速判断
在进行 MySQL 日志分析时，第一步是快速了解磁盘上日志文件的总量和分布。通过操作系统层面的命令，可以快速判断日志是否出现异常增长，从而判断是否需要进入下一步的数据库层诊断。关注点包括哪些目录在膨胀、最近的写入活动，以及日志轮转是否正常。
常用的操作系统命令可以帮助你在不进入数据库的情况下获得初步线索。通过对比不同目录的大小，可以快速定位日志膨胀的源头。基线对比是判断增长是否异常的关键。
du -sh /var/log/mysql /var/lib/mysql
du -sh /path/to/your/mysql/logs
此外，如果你的服务器使用系统日志管理工具（如 rsyslog、logrotate），也要检查轮转策略是否导致日志文件持续滚动，进而造成磁盘占用持续上升。轮转策略与日志保留周期往往直接影响日志文件总量。
查看 MySQL 日志的实际文件大小
除了目录级别的大小外，实际的日志文件大小分布在具体的日志文件中。通过数据库本身的查看，可以得到更精确的日志分布信息，帮助你快速判断哪些日志在膨胀。重点在于区分二进制日志、慢查询日志、通用日志等的当前大小。
MySQL 的二进制日志、慢查询日志、通用日志等实际文件大小分布在数据目录或日志目录中。通过 MySQL 提供的命令，可以直接看到当前的日志文件及其大小。请关注日志文件的命名及其对应的大小。
SHOW BINARY LOGS;
SHOW VARIABLES LIKE 'slow_query_log_file';
SHOW VARIABLES LIKE 'general_log_file';
SHOW VARIABLES LIKE 'log_bin';
当你看到某个日志文件的尺寸远超其他文件时，说明该日志在短时间内记录了大量事件，或者轮转未按预期进行。此时需要进入更深入的定位步骤，结合系统和数据库级别信息共同分析。要点在于确认日志开启状态和文件路径是否符合预期。
定位日志增长的原因
数据库层面：二进制日志、慢查询日志、错误日志
日志增长的典型原因往往来自数据库层面的持续写入，例如二进制日志持续产生日志、慢查询导致的日志积累，以及错误日志的持续输出。通过检查数据库级别的日志设置，可以快速判断是否属于数据库本身的产出导致的增长。核心指标是日志开启状态、保留策略，以及当前日志的累积大小。
要点包括查看二进制日志的文件清单和总大小，以及慢查询日志的启用状态与文件路径。通过这些信息，你可以快速判断是否需要调整保留期、清理旧日志或调整阈值。关键命令帮助你确认当前配置。
SHOW BINARY LOGS;
SHOW VARIABLES LIKE 'expire_logs_days';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'slow_query_log';
若需要进一步分析慢查询导致的日志增长，可以暂时开启慢查询日志并查看慢查询日志中最耗时的查询语句，以便后续优化。示例为了解冻结点和优化方向提供依据。
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- 单位：秒
应用层面：慢查询、并发、事务
应用层面的行为同样会直接影响日志的大小。例如，某些热点查询的重复出现、并发请求的激增、以及未提交或长时间运行的事务都会导致慢查询日志和通用日志的快速增长。通过分析应用端的查询分布和执行时间，可以快速定位增长的实际场景。
你可以结合性能分析工具与日志，以确认哪些应用场景触发了大量日志输出。这些信息对于后续的查询改写、索引优化和连接池调整都至关重要。要素包括高频查询、慢速操作以及高并发时的日志特征。
SELECT EVENT_ID, SQL_TEXT, TIMER_WAIT FROM performance_schema.events_statements_history_long
ORDER BY TIMER_WAIT DESC LIMIT 10;
存储层面：InnoDB redo 日志与 undo 日志
InnoDB 的 redo 日志（ib_logfile*）和 undo 日志也会在高负载时产生大量日志输出，尤其是在大事务、长事务或频繁提交的场景。了解 innodb_log_file_size、innodb_log_files_in_group 等参数的当前值，有助于判断是否需要调整日志文件大小和数量，以避免频繁扩展导致的写放大和日志增长。
通过以下命令可以快速了解日志配置和当前状态，从而判断是否存在冗余日志输出或需要优化的地方。关键点是日志组大小与组数，以及在高并发场景下的吞吐能力。
SHOW VARIABLES LIKE 'innodb_log_file_size';
SHOW VARIABLES LIKE 'innodb_log_files_in_group';
如果发现 redo 日志文件过小导致频繁滚动与合并，或者组数过多而导致写放大，可以考虑调整参数并进行容量评估。请在变更前进行充分测试，以避免对数据库稳定性造成影响。注意：修改 innodb_log_file_size 等参数通常需要先停止数据库、移动现有日志文件再重启。
快速排查流程示例
采集阶段
在开始深入诊断前，先进行基线采集，记录当前日志文件的大小、轮转策略及日志开启状态。这个阶段的目标是建立对比基线，以便后续定位增长来源。步骤要点包括：记录日志目录、输出当前日志文件大小、确认日志类型启用情况。
通过快速采集，你可以获得初步线索：某类日志是否迅速膨胀、某个时间段是否与应用峰值相关等。随后再结合数据库与应用层面的数据，进行综合分析。
# 1) 记录基线日志目录大小
du -sh /var/log/mysql
du -sh /var/lib/mysql# 2) 查看当前二进制日志与慢查询日志状态
mysql -uroot -p -e "SHOW BINARY LOGS; SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'log_bin';"
诊断阶段
诊断阶段聚焦在找出增长的具体来源，是二进制日志增长、慢查询输出，还是应用层并发叠加所致。结合系统时间戳、日志文件名与 MySQL 的状态变量，可以快速锁定原因。核心动作包括：分析日志文件名对应的时间段、对比慢查询日志的查询分布，以及检查数据库参数的设置。
对诊断阶段而言，最有价值的输出通常来自以下几个方面：二进制日志的总大小、慢查询日志的写入速率、以及 redo/undo 日志的配置状态。
SHOW BINARY LOGS;
SHOW VARIABLES LIKE 'expire_logs_days';
SHOW VARIABLES LIKE 'innodb_log_file_size';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'slow_query_log';
处置阶段
处置阶段聚焦在落地改动，例如调整日志轮转、优化慢查询、调整 redo/undo 日志参数，以实现对日志大小的有效控制。此阶段的目标是确保日志增长在可控范围内，同时不影响数据库的正常运行。关键点包括：调整轮转策略、优化慢查询、以及在必要时扩容日志容量。
在执行变更前，务必进行回滚计划与回滚测试，确保在生产环境中快速恢复。
# 例：调整慢查询日志阈值与开启状态（谨慎在生产环境执行）
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;# 例：调整 InnoDB 日志大小（需要重启数据库）
# 修改 my.cnf 中：
# innodb_log_file_size = 256M
# 重新启动 MySQL 即可生效
