分析MySQL系统资源日志有助于排查性能瓶颈、优化查询效率和保障数据库稳定运行。关键在于理解日志类型、采集资源使用数据，并结合工具进行可视化与趋势分析。
启用并查看MySQL相关日志
MySQL本身不直接记录CPU、内存等系统资源日志，但可通过以下日志间接反映资源使用情况：
慢查询日志（slow query log）：记录执行时间超过指定阈值的SQL语句，是分析性能问题的第一手资料。通过设置long_query_time和开启slow_query_log来启用。 通用查询日7志（general query log）：记录所有SQL操作，可用于追踪请求频率，但对性能有影响，建议临时开启。 错误日志（error log）：记录启动、关闭及运行时的异常信息，帮助判断是否因资源不足导致崩溃。 Performance Schema 和 INFORMATION_SCHEMA：提供实时的线程、锁、内存使用等内部状态信息。结合操作系统日志监控资源使用
MySQL的资源消耗需借助系统级工具采集：
使用top、htop观察MySQL进程的CPU和内存占用。 通过iostat或iotop检查磁盘I/O是否成为瓶颈，特别是InnoDB日志或数据文件读写延迟。 利用vmstat查看内存交换（swap）情况，频繁swap可能说明物理内存不足。 将上述命令结果定期记录到日志文件，便于后续分析趋势。使用专业工具进行综合分析
手动分析效率低，推荐使用集成化工具提升效率：
pt-query-digest（Percona Toolkit）：解析慢查询日志，生成执行时间、扫描行数、锁等待等统计报告，快速定位高负载SQL。 MySQL Enterprise Monitor / Percona Monitoring and Management (PMM)：提供图形化界面，实时展示QPS、连接数、缓冲池命中率、I/O吞吐等关键指标。 sys schema：基于Performance Schema构建的易读视图，如sys.statements_with_long_waiting可查等待最久的语句。建立定期分析机制
资源问题往往随时间积累显现，应形成常态化检查流程：
每日检查慢查询日志增量，识别新增慢SQL。 每周汇总系统资源使用峰值，比对业务高峰时段是否存在关联。 对频繁出现的全表扫描、未使用索引的语句及时优化。 设置告警阈值，如连接数超过最大连接的80%或I/O等待超过50%。基本上就这些。关键是把MySQL内部状态和系统资源数据结合起来看，才能准确判断是SQL问题、配置不当还是硬件瓶颈。
