MySQL 5.7.17，针对日志系统展开深度解析，从错误排查方面，直至性能优化实战。

于 MySQL 数据库平常的运维之内境里，日志系统身为数据库管理员也就是 DBA 以及开发人员去洞察数据库运行状况、诊断故障以及展开性能调优的“眼睛”。

本文会依据 MySQL 5.7.17 版本（GPL）于 Ubuntu 16.04 环境里的实践，深入剖析核心日志的分类，以及配置与管理技巧，以此来帮助读者构建规范的数据库运维体系。

mysql日志文件分类_数据库MySQL错误日志_错误日志

一、MySQL 日志体系架构概览

MySQL 通过多种日志文件详细记录数据库的各类活动。

理解这些日志的分类与作用，是进行精准问题定位的前提。

主要日志类型包括：

错误日志（Error Log）用于记录，MySQL服务器启动、运行或者停止时的严重错误以及警告，它是排查数据库故障的首选入口。

2. 有这么一种 慢查询日志（Slow Query Log），它会去捕获那些执行时间比预先设定的阈值（long_query_time）还要长的 SQL 语句，而这些语句可是 SQL 性能优化的核心依据哟。

3. 二进制日志，也就是Binary Log，它记录着所有更改数据的语句，或者是行级事件，其主要用途在于数据复制，也就是Replication，以及基于时间点的数据恢复，即PITR。

4. 通用查询日志（General Query Log）：它会记录客户端的全部连接情况，以及所执行的 SQL 语句，鉴于记录的数量非常大，一般只在进行详细调试的阶段才开启这项记录。

mysql> show variables like 'log_error'G;

本文重点聚焦于错误日志与慢查询日志的深度应用。

二、错误日志：数据库故障诊断的基石

MySQL初始化的信息被错误日志记录下来，启动中止的情况也在错误日志中有记录，InnoDB事务恢复的相关内容同样被错误日志所记载，复制错误等关键信息也都在错误日志里有所呈现。

mysql日志文件分类_数据库MySQL错误日志_错误日志

当数据库连接失败或突然宕机时，应第一时间检查此日志。

1. 定位错误日志文件

借助登录 MySQL 客户端，施行以下命令，能够精准获取当下错误日志的物理路径。

mysql> SHOW VARIABLES LIKE 'log_error';

在典型的Linux系统里边，该值有可能默认成为stderr，（此为重定向至数据目录下的主机名.err文件），或者借助配置文件明确地指定路径。

2. 错误日志解读实战

#默认的阀值时间
mysql> show variables like 'long_query_time'G;

假设数据库无法启动，查看错误日志通常会看到类似信息：

有错误提示，此句为，“[ERROR]”，接着是，“InnoDB:”，然后是，“Unable to lock”，再接着是，“./ibdata1”，之后是，“error:”，最后是，“11”。

#是否开启
mysql> show variables like 'slow_query_log'G;

该错误提示显示，InnoDB的表空间文件被别的进程锁定了，一般是由于之前MySQL没有正常关闭，致使进程有残留，或者文件锁没有被释放。

解决思路是检查并 kill 残留进程，或重启操作系统。

三、慢查询日志：性能优化的导航仪

mysql> set global slow_query_log='ON';

在生产的环境里头，超过百分之八十的性能方面的问题，通常是由百分之二十的低效的SQL引发的。

数据库MySQL错误日志_错误日志_mysql日志文件分类

慢查询日志正是定位这些“罪魁祸首”的关键工具。

1. 启用与配置慢查询日志

考虑到开启日志会致使一定的 I/O 开销产生，因而建议仅于性能调优的环境之中，或者开发测试的环境里面，按照需求来开启。

mysql> show variables like 'slow_query_log_file'G;

查看当前状态与阈值：

mysql> SHOW VARIABLES LIKE 'slow_query_log%';
mysql> SHOW VARIABLES LIKE 'long_query_time';

mysql日志文件分类_错误日志_数据库MySQL错误日志

具有默认赋值为 10.000000 秒的 long_query_time，意味着用来记述那些执行所用时间超越 10 秒的 SQL。

动态开启与调整阈值（无需重启）：

xuliugen@xuliugen:~$ sudo mysqldumpslow /var/lib/mysql/xuliugen-slow.log

mysql> SET GLOBAL slow_query_log = ON;
mysql> SET GLOBAL long_query_time = 1; -- 调整为记录超过 1 秒的 SQL

数据库MySQL错误日志_错误日志_mysql日志文件分类

留意，那关于long_query_time的更改，对于当下的会话，也就是Session而言，是不会产生效果的。

新阈值只于新构建的连接里起作用，这属于 MySQL 5.7 的一项会话层面特性，得退出再重新登录来验证。

错误日志_数据库MySQL错误日志_mysql日志文件分类

2. 存储方式与高级特性

存于文件（FILE）以及表（TABLE）这般的两种存储方式，慢查询日志是予以支持的，默认状况之下会写入文件。

通常位于 MySQL 数据目录下的，被称作默认文件路径，其命名格式为 主机名-slow.log。

mysql> show variables like 'log_output'G;

修改存储方式为表：

mysql> SET GLOBAL log_output = 'TABLE';

数据库MySQL错误日志_错误日志_mysql日志文件分类

当进行修改之后，慢查询的记录会被写入到 mysql.slow_log 这个系统表当中去，它是支持运用 SQL 语句来开展查询分析操作的，譬如是像 SELECT FROM mysql.slow_log ORDER BY start_time DESC LIMIT 5; 这样的语句。

精细化控制（5.7 新增特性）：

数据库MySQL错误日志_错误日志_mysql日志文件分类

于5.7版本里，有着重要控制功效、发挥关键作用的参数，是log_slow_admin_statements ，以及 log_queries_not_using_indexes。

：log_slow_admin_statements是用来判定是不是要记录慢速管理语句的，像 ALTER TABLE这样的，还有 OPTIMIZE TABLE也是哦。

代码“log_queries_not_using_indexes”，它起到的作用乃是决定，是否对那样一些查询进行记录，这些查询即便执行起来速度很快，然而却并未使用索引。

mysql> set global log_output='TABLE';

《生产环境建议》：慎重开启《log_queries_not_using_indexes》，鉴于未运用索引却进行全表扫描的小表查询或许会被频繁执行，致使慢日志快速扩张，耗尽磁盘空间。

通常建议在开发环境开启以优化索引设计。

错误日志_mysql日志文件分类_数据库MySQL错误日志

3. 慢查询日志分析案例

要是我们把阈值设定成 1 秒，接着进行两次模拟查询，其中一次用时是 0.9 秒，这次并未记录，另一次用时为 1.1 秒，这次是有记录的呢。

mysql> show create table mysql.slow_logG;

查看慢日志文件：

# Time: 2026-02-28T12:00:10.123456Z
# User@Host: root[root] @ localhost []  Id:  1234
# Query_time: 1.100000  Lock_time: 0.000000 Rows_sent: 100  Rows_examined: 10000
SET timestamp=1709092810;
SELECT  FROM large_table WHERE non_indexed_column = 'some_value';

数据库MySQL错误日志_mysql日志文件分类_错误日志

日志清楚明晰地展现出了执行的时间，也就是 Query_time，还有锁的时间，即 Lock_time，以及扫描的行数，称为 Rows_examined，更有具体的 SQL 语句。

将 mysqldumpslow 工具予以结合，像 mysqldumpslow -s c -t 10 /var/lib/mysql/hostname-slow.log 这样，能够依据执行次数或者时间来开展排序，从而迅速地对 TOP N 的“重量级”SQL 进行定位。

总结

mysql> select sleep(10);

搞清楚 MySQL 错误日志的配置方式以及分析办法，弄明白 MySQL 慢查询日志的配置方式以及分析办法，是进行数据库运维进阶时必须要修习的课程。

经由针对错误日志予以监控，能够迅速止住故障；借助对慢查询日志展开深度剖析，可不断优化 SQL 性能，保证业务系统于数据量增加之际依旧维持高效稳定。

数据库MySQL错误日志_mysql日志文件分类_错误日志