MySQL作为最常用的关系型数据库，其自身产生的日志是排查故障的核心依据。错误日志负责记录服务进程级的异常，通用查询日志则完整保留客户端的所有请求。理解它们的机制，是运维和开发定位数据库问题的第一步。
一、MySQL错误日志是什么
错误日志（Error Log）是MySQL服务端启动时创建、运行过程中持续写入的日志文件。它记录了mysqld进程从初始化、存储引擎加载、网络连接监听，到运行期出现的各类警告与致命错误。不同于二进制日志只记录数据变更，错误日志关注的是“数据库服务本身是否健康”。
在默认安装中，错误日志路径通常由log_error系统变量指定。可以通过如下命令查看当前配置：
SHOW VARIABLES LIKE 'log_error'; -- 常见结果：/var/log/mysql/error.log 或 ./hostname.err
当发生主从复制断开、表损坏、内存分配失败等情况时，错误日志会输出带有时间戳和线程ID的明细。例如下面这段记录表明从库IO线程连接主库失败：
2023-08-12T02:14:33.221234Z 5 [ERROR] Slave I/O for channel '': error connecting to master 'repl@192.168.0.1:3306' - retry-time: 60 retries: 1, Error_code: 2003
从运维角度看，错误日志是告警系统的数据源头。很多监控工具直接tail该文件，匹配ERROR或Warning关键字来触发通知。因此保持错误日志级别合理、不过度刷屏，才能确保真正严重的问题不被淹没。
二、通用查询日志的作用与开销
通用查询日志（General Query Log）会按时间顺序记录所有到达MySQL服务器的客户端连接、断开以及执行的每一条SQL语句，无论这条语句是否报错、是否命中索引。它相当于数据库的“黑匣子”，在排查诡异业务逻辑或审计场景非常有用。
开启方式分为动态开启与配置文件开启。动态开启适合临时抓包：
SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/tmp/mysql_general.log'; -- 也可输出到表：SET GLOBAL log_output = 'TABLE';
需要注意的是，通用查询日志对性能影响显著。在高并发写入场景下，每条语句都落盘会导致磁盘IO飙升，甚至反压业务吞吐。因此生产环境一般仅在复现问题期间短期开启，并在结束后立即关闭：
SET GLOBAL general_log = 'OFF';
与慢查询日志不同，通用查询日志不区分执行快慢，它关注的是“发生了什么”。当错误日志显示服务正常，但业务反馈数据不对时，通用查询日志能还原出具体是哪个连接在什么时候执行了哪条UPDATE。
三、两者结合的实际排查案例
某日错误日志突然出现大量“Aborted connection”记录，但慢查询日志为空。此时单看错误日志只能知道连接被异常中断，无法定位触发点。我们开启通用查询日志后，发现有一个批处理脚本每秒建立新连接却不释放，触发了max_connections限制。
对应的错误日志记录如下：
2023-09-01T10:22:11.334Z 12 [Warning] Aborted connection 12 to db: 'order' user: 'batch' host: '192.168.0.1' (Got timeout reading communication packets)
通用查询日志片断则显示该脚本循环执行：
2023-09-01T10:22:10.901Z 13 Connect batch@192.168.0.1 on order 2023-09-01T10:22:10.902Z 13 Query SELECT * FROM t_order WHERE id=1 2023-09-01T10:22:10.903Z 13 Quit 2023-09-01T10:22:10.904Z 14 Connect batch@192.168.0.1 on order
通过交叉比对，我们确认问题源于应用连接池配置失误，而非数据库端故障。修复连接复用逻辑后，错误日志中的警告消失。这个案例说明：错误日志告诉你“病了”，通用查询日志告诉你“怎么病的”。
四、常见误区与配置建议
不少团队把通用查询日志当成永久审计方案，这是错误且危险的。它不支持按库过滤，且文本量巨大，长期开启既占空间又拖慢实例。如果确有审计需求，应使用企业版审计插件或代理层抓包。
另一个误区是忽视错误日志的轮转。如果不配置logrotate，error.log会无限增长，导致磁盘写满引发二次故障。推荐在Linux下增加如下轮转配置：
/var/log/mysql/error.log {
daily
rotate 7
missingok
compress
postrotate
mysqladmin flush-logs
endscript
}
对于通用查询日志若输出到表（mysql.general_log），需注意该表为CSV引擎，大量写入同样会阻塞系统表。因此临时排查完务必切回FILE或关闭。合理运用这两种日志，才能用最小成本保障数据库可观测性。
五、快速定位问题的标准流程
当收到数据库异常告警时，建议遵循“先错误后通用”的顺序：第一步登录服务器查看错误日志尾部，确认是否有ERROR级条目及关联模块；第二步若错误日志无明确SQL线索，在低峰期动态开启通用查询日志，复现操作后分析连接与语句序列；第三步关闭通用日志，根据结论修复代码或参数。
该流程可沉淀为内部SOP，配合如下检查清单提升效率：
- 错误日志中是否出现主从、存储引擎、OOM相关关键字
- 通用查询日志中异常连接的来源IP与账号
- 问题时间段内是否有大量相同模板的短连接
- 慢查询与通用日志的时间轴是否吻合
掌握上述方法后，即便面对复杂的偶发故障，也能在半小时内外推出根因，而不是盲目重启实例。MySQL的日志系统虽简单，却是排查路上最可靠的伙伴。
MySQL错误日志通用查询日志slow_query修改时间：2026-08-09 11:33:40