MySQL general log通用查询日志：原理、配置与故障排查实战-北京尧图网络

MySQL 的 general log 属于那种平时没人想起、出事时第一个被想起的东西。它的中文叫通用查询日志干的活儿很朴素把服务器端收到的每一条语句、每一次连接、每一次断开原封不动记下来。慢查询日志只挑慢的记二进制日志为了复制和恢复做了裁剪和封装错误日志只关心启停和崩溃只有 general log 是全量流水账。它不能提升性能不能帮你优化索引但当你要回答“这条语句到底是谁发的”“这个连接为什么连上来又立刻断掉”“上线前这个模块到底跑了多少种 SQL”这类问题时它几乎是唯一的答案来源。这篇内容适合三类人看被线上偶发问题折腾过、想临时抓一次现场的后端开发需要做 SQL 行为审计、又不想上重型审计组件的 DBA以及刚开始接触 MySQL、想知道各类日志分工的初学者。下面我按“它是怎么工作的—参数怎么配—怎么开怎么关—怎么用它破案—踩过哪些坑”的顺序把这些年攒下来的东西摊开讲。1. general log 的定位与记录边界1.1 一条日志是怎么从连接握手走到磁盘的要理解 general log 的行为先得知道它在服务器内部处于哪个位置。客户端连上来之后MySQL 的网络层完成握手解析器拿到语句文本接着进入权限检查、优化、执行的完整流程。general log 的写点非常靠前——它记录的是服务器端收到的语句而不是执行成功的语句。语法错的、权限不足的、表不存在的语句一样会写进去这恰恰是它排查问题时的最大优势你能看到“发过来但没跑成”的东西。日志的写入是按事件粒度的常见的 command_type 有Connect、Query、Quit、Init DB、Prepare、Execute、Field List这几类。Connect那一行会带出用户名和来源地址后面跟着的Query才是具体语句。客户端断开时补一条Quit。所以一份完整的日志读下来你能还原出“谁在什么时间连上、建了哪个库、发了哪些语句、什么时候走的”这条完整链路。写入时机上它是在语句被处理的过程中追加的不是事务提交时才写也不参与事务回滚。一条ROLLBACK掉的语句照样躺在日志里。这一点经常让第一次用它的人困惑日志里有这条 SQL可表里没数据。不是日志错了是它本来就只记“发出去了什么”。1.2 和 slow log、binlog、error log 的分工边界这四个日志经常被混着问我把它们的分工列一下后面选型就不会乱。日志类型记录范围主要用途是否默认开启general log全部收到的语句与连接事件临时排查、行为审计、抓现场否slow log超过阈值的语句与未走索引语句性能优化、找出耗时大户否阈值可配binlog数据变更类语句复制、按时间点恢复、变更捕获是8.0 默认开error log启停、崩溃、严重错误故障诊断、启动失败定位是关键差别在于“全量”和“有选择”。binlog 只记变更SELECT一律不进slow log 只记慢的快得离谱但量极大的语句反而不进error log 只记异常。只有 general log 是无差别全收。这也直接决定了它的代价——它是这四个里唯一一个会把系统开销和磁盘占用同时拉起来的日志。还有一个容易搞错的点general log 里没有结果集。它只记语句本身不记返回了多少行、返回了什么内容。所以想靠它判断“这条 SQL 查出来多少数据”行不通得结合别的信息去推。1.3 它记什么、坚决不记什么把边界说清楚能省掉很多无效尝试。记的东西客户端发来的所有语句文本、连接与断开的动作、连接的来源地址与用户名、建立连接后选择的默认库、预处理语句的 Prepare 与 Execute 动作、存储过程和触发器内部实际执行的语句。不记的东西返回的结果集、影响行数、执行耗时这是它和 slow log 最大的能力缺口、锁等待信息、字段元数据。Field List这类命令只在新版驱动做元数据查询时短暂出现不用深究。这里必须单独强调一条安全红线general log 记的是原始文本意味着如果某条语句里带了明文口令比如建用户时的IDENTIFIED BY、或者应用初始化脚本里硬编码的凭据它会一字不差地落盘。日志文件默认在那台机器的数据目录里谁能读文件谁就能看到这些内容。我在实际使用中形成的习惯是临时开启前先确认这个时间段内不会有账号变更操作采完立刻关掉并删除文件。把它当临时工具不要当长期档案。2. 四个核心参数每一个都决定日志怎么落地2.1 log_output写文件还是写表代价差一个量级log_output决定日志往哪儿写取值是FILE、TABLE、NONE并且可以组合成FILE,TABLE。新版默认是FILE。FILE模式的写入就是往一个追加文件里顺序写走的是操作系统的顺序 I/O没有事务、没有索引维护、没有行锁。它的开销相对可控代价主要落在磁盘带宽和文件系统缓存上。TABLE模式写的是mysql.general_log这张表这张表用的是 CSV 存储引擎没有索引、不支持事务、每次写入都要走一遍表层的处理逻辑。两者放在同一个高并发负载下对比差距明显文件模式通常是吞吐下降一到三成表模式在写密集场景里可能把响应时间拉高好几倍。所以选型的逻辑很直白需要短时间抓大量现场用FILE需要边采边用 SQL 查或者采集窗口很短、QPS 不高用TABLE。FILE,TABLE这个组合我基本不用——两份开销叠加收益却很有限。注意log_output改成TABLE之前先确认mysql.general_log这张表还在。有些环境在升级或者迁移时把系统库的这张表清理掉了改完log_output直接开日志会报错或者悄悄什么都不写。2.2 general_log 与 general_log_file动态生效的时间差general_log是总开关取值ON或OFF作用域是全局而且是动态变量改完立即生效不用重启实例。这一点很关键——很多文档里写着“需要重启”那是老版本的行为现在不需要了。general_log_file指定文件路径。这里有个必须知道的坑光改这个变量MySQL 不会立刻换文件。它在下一次打开日志文件时才生效。也就是说你把路径从 A 改成 B但开关一直是ON服务器还在往 A 里写。正确的做法是SET GLOBAL general_log OFF改路径再SET GLOBAL general_log ON这时才会创建并写入 B。在 8.0 上还有个更省事的写法SET PERSIST general_log ON。它会把设置同时写进持久化配置文件重启后依然生效。反过来说如果你只是想临时开一下千万别用PERSIST不然哪天重启完发现日志又开了磁盘很难看。用SET GLOBAL就够了重启自然复位。2.3 sql_log_off给单个会话静音这个变量知道的人不多但特别实用。sql_log_off是会话级变量设为ON之后当前这个连接发出的语句就不再写进 general log 了其他连接不受影响。它的价值在于降噪。比如你开了全局日志但某个定时任务或者监控探针每五秒发一次SELECT 1把日志刷得全是无用行这时候让那个连接自己执行一次SET sql_log_off ON日志立刻干净。又比如你在排查问题一边开着日志一边想跑几条自己的验证语句不想污染采集结果也是同样的做法。设置这个变量需要SUPER权限8.0 上是SYSTEM_VARIABLES_ADMIN普通应用账号用不了。这也合理——要是谁都能关掉自己的日志记录审计就失去意义了。2.4 权限与访问控制谁能看、谁能改改general_log需要SUPER或SYSTEM_VARIABLES_ADMIN这是硬门槛。查mysql.general_log表需要SELECT权限普通业务账号默认没有需要单独授权。我见过的两种极端都不太好。一种是所有开发共用一个高权限账号随手就能SET GLOBAL general_log ON某天有人开完忘了关磁盘撑爆整个实例不可写。另一种是权限收得极死真出问题了没人能取证只能等 DBA 上线。比较务实的做法是日常把开关权限收敛到少数人手上但保留一套“限时开启”的流程——申请、开启、采集固定时长、自动关闭。这套流程可以用一个带超时的存储过程或者外部调度脚本来实现本质上是给“忘记关”这个人类通病上一道保险。3. 从开启到关闭的完整实操链路3.1 开启之前必须确认的三件事第一件是确认当前值别在已经开着的基础上又开一遍。跑一下SHOW GLOBAL VARIABLES LIKE general_log%;能看到开关状态、文件路径再跑SHOW GLOBAL VARIABLES LIKE log_output;看输出位置。这两个查询不耗资源养成先看一眼的习惯。第二件是估算磁盘。这个下面单独讲但顺序上必须在开启前做完因为一旦开起来磁盘增长速度取决于业务流量你控制不了。第三件是确认采集目标。你到底想抓什么是全量抓十分钟还是只想看某个用户、某个库的行为目标不同采集窗口长度和后续过滤方式完全不同。漫无目的地开着最后拿到几十 G 日志里翻不出有用信息是很常见的结果。提示开启前先执行一次FLUSH GENERAL LOGS;。它会在日志处于关闭状态时不出任何动作但如果之前残留了旧的缓冲或者文件句柄这一步能保证你拿到的是一份干净的、从当前时刻开始的日志。3.2 文件模式的开启、验证与关闭文件模式的完整动作序列如下。先记录当前状态改路径可选打开开关-- 1. 记录当前配置便于事后复位 SHOW GLOBAL VARIABLES WHERE Variable_name IN (general_log, general_log_file, log_output); -- 2. 指定输出到文件如果需要改路径改完必须重新开关一次 SET GLOBAL log_output FILE; SET GLOBAL general_log OFF; SET GLOBAL general_log_file /var/lib/mysql/general_trace.log; SET GLOBAL general_log ON; -- 3. 确认已经在写 SHOW GLOBAL VARIABLES LIKE general_log;验证的方式不是看变量而是看文件有没有长大。用ls -l连续看两次文件大小同时让另一个连接随便发一条SELECT 1如果文件体积变了说明链路通了。这一步别省我见过配置改完变量显示ON、文件却一直是 0 字节的情况原因是路径所在目录的属主或权限不对MySQL 打不开文件只会在错误日志里留一行提示很容易被忽略。关闭就是一句SET GLOBAL general_log OFF;。关完之后再确认一次文件大小不再变化然后按需处理文件——保留、压缩归档、或者直接删掉。3.3 表模式写进 mysql.general_log 的用法与限制表模式的最大好处是能用 SQL 直接查、直接聚合省掉了把文件倒腾到别处的步骤。开启方式和文件模式类似把log_output换成TABLESET GLOBAL log_output TABLE; SET GLOBAL general_log ON; -- 看看有没有内容进来 SELECT COUNT(*) FROM mysql.general_log; -- 按线程统计语句数量快速找出话最多的连接 SELECT thread_id, command_type, COUNT(*) AS cnt, MIN(event_time) AS first_seen, MAX(event_time) AS last_seen FROM mysql.general_log GROUP BY thread_id, command_type ORDER BY cnt DESC LIMIT 20;表结构有六列event_time、user_host、thread_id、server_id、command_type、argument。argument存的就是语句原文。它有几个硬限制必须提前知道。第一这张表是 CSV 引擎没有索引任何查询都是全表扫描日志写了十万行之后一个简单的GROUP BY就可能跑几十秒。第二日志处于开启状态时不能对这张表做TRUNCATE或者ALTER会直接报错必须先关日志。第三CSV 引擎对字段长度和特殊字符的处理比较粗糙语句里有换行或者特殊字符时查出来的内容可能不太好看。真要在表模式上做分析我的做法是采完之后立刻关日志把表RENAME成一个普通表转成支持索引的引擎再在thread_id、event_time上建索引慢慢查。代价是多几步操作但查询体验完全是两个层次。3.4 一条日志记录到底长什么样文件模式下每一行的结构是四段用制表符分隔时间戳、线程号、命令类型、参数。新版的时间戳带微秒和时区偏移形如2024-05-20T10:12:33.12345608:00老版本是240520 10:12:33这种紧凑格式。跨版本对比日志时要注意这个差异别写死了正则。一个典型的片段大致是这样2024-05-20T10:12:31.00311408:00 8 Connect app_user10.0.0.21 on app_db 2024-05-20T10:12:31.00520008:00 8 Query SET NAMES utf8mb4 2024-05-20T10:12:31.00590008:00 8 Query SET autocommit0 2024-05-20T10:12:31.12000408:00 8 Query SELECT id, name FROM orders WHERE id 88231 2024-05-20T10:12:31.12150008:00 8 Quit读这段能拿到不少信息线程 8 从某个地址连上来选了app_db先发了两条驱动的初始化语句然后才是业务查询前后不到 120 毫秒就断开了。这个“连接、初始化、查询、断开”的完整周期压缩在百毫秒内本身就是一条线索——这是典型的短连接用法。如果同样的模式在日志里密集出现说明连接池配置有问题后面会细说。还有一个细节值得留意驱动初始化语句往往占了日志行数的一大半。SET autocommit、SET NAMES、SET SESSION sql_mode这类东西每条连接都要来一遍业务语句反而没几条。做统计的时候要先把这些过滤掉否则分析结果全被噪音带偏。3.5 磁盘容量估算与轮转配置这是最容易翻车的地方因为 general log没有任何自动轮转和大小上限。文件会一直长表会一直加行直到你把开关关掉或者磁盘满掉。先算一笔账估算公式很简单每日增量 ≈ 单条平均字节数 × 每秒语句数 × 86400单条平均字节数怎么取别拍脑袋。抓一段一百行的样本用wc -c除以行数就有准确值。经验上带时间戳和线程号的普通业务语句在 150 到 300 字节之间带长IN列表或者大批量INSERT的会到几 KB。取 200 字节是个偏保守的中间值。按 200 字节、每秒 800 条语句算200 × 800 × 86400 ≈ 13.8 GB/天。这只是一个中等负载的实例高峰时段 QPS 翻几倍的话日增量轻松破三十 G。所以开启前必须做这个乘法而不是开完再看。轮转的做法有两个。简单直接的一种是手动控制窗口# 开启 mysql -e SET GLOBAL general_log ON; sleep 600 # 关闭 mysql -e SET GLOBAL general_log OFF; # 归档并压缩 gzip /var/lib/mysql/general_trace.log需要长期开着又怕文件爆的用logrotate配合FLUSH GENERAL LOGS。配置大致这样/var/lib/mysql/general_trace.log { size 2G rotate 5 missingok notifempty create 640 mysql mysql postrotate mysql -e FLUSH GENERAL LOGS; 2/dev/null || true endscript }FLUSH GENERAL LOGS的作用是关闭当前文件句柄并重新打开配置路径上的文件。logrotate默认是“改名后新建”的方式改名之后 MySQL 手里还攥着旧文件的句柄只有执行这一步它才会去打开新建的那个空文件。这一步漏了日志会继续往改名后的旧文件里写新建的文件一直空着——这是个非常经典的坑。3.6 收尾关闭、清理、复位三步采集结束的收尾动作我习惯固定成三步形成肌肉记忆。第一步关开关SET GLOBAL general_log OFF;。这一步之后文件不再增长但已经打开的文件句柄还在不算完全干净。第二步处理数据。文件模式直接压缩归档表模式先TRUNCATE再考虑转存SET GLOBAL general_log OFF; TRUNCATE TABLE mysql.general_log;第三步复位配置。如果之前改过general_log_file把它改回默认值或者原来的路径log_output也复位成默认的FILE。这一步容易被忽略等到下次别人再开日志发现输出位置不对又要重新查一遍。注意如果你用了SET PERSIST复位的时候也得用SET PERSIST或者RESET PERSIST否则重启之后旧配置还会回来。4. 三个能真正解决问题的使用场景4.1 追查“这条语句到底是谁发的”这是 general log 最经典的用法。线上出现了一条诡异的语句——比如某个大表的全表更新、某个不该出现的DELETE——但你不知道它从哪来。应用代码里搜不到ORM 日志里也没有各种可能都排查过了还是没结论。做法是在问题复现的时间窗口里开一小段日志用语句特征去捞# 捞出所有涉及目标表、且是写操作的语句上下文 awk -F\t NF4 $3Query $4 ~ /update[[:space:]]orders/ {print $1, $2, $4} \ general_trace.log | head -50拿到thread_id之后用这个线程号把整个会话的语句序列都捞出来awk -F\t $2512 {print} general_trace.log这个会话序列的价值在于它不只告诉你“谁发的”还告诉你“发之前做了什么”。你会看到这个连接先查了一张配置表再查了一张权限表最后才发出那条致命更新——这直接指向了代码里的某个业务分支而不是漫无目的地搜代码。我靠这一招定位过的“幽灵语句”根因基本都藏在这个前后文里单看那条语句本身反而看不出来。4.2 识别连接风暴与短连接问题第二个高频场景是连接数异常。监控上看到连接数一直往上爬或者Threads_created涨得飞快第一反应通常是连接池没配好但要坐实这个判断general log 是最直接的证据。看日志里的连接模式。健康的连接池日志应该是“少数几个线程号长长的一串语句最后几乎看不到Quit”有问题的短连接日志长这样一堆不同线程号每个线程号下面只有三四行——Connect、两条SET、一条业务查询、Quit然后线程号就消失了。统计方式很简单# 每个线程号对应多少行日志 awk -F\t NF3 {print $2} general_trace.log | sort | uniq -c | sort -n | head -20如果发现大量线程号只有个位数行数而且Connect的时间戳非常密集基本可以断定要么连接池被关掉了每次都新建连接要么池子的最小空闲连接数配得太低要么某个框架在每次请求后主动关了连接。这三种情况的修法完全不同但现象在日志里是同一个得结合应用侧配置去对上。还有一个更细的信号看Connect行的来源地址分布。如果同一个 IP 在极短时间内产生了几十个不同线程号说明那个节点上的连接复用彻底失效了压力全压在数据库的握手和权限校验上。4.3 上线前的 SQL 行为审计这个用法不太常见但我觉得价值很高。新模块上线前在预发环境开一段日志把完整的测试用例跑一遍然后从日志里把实际发出的 SQL 全捞出来人工过一遍。看的不是性能而是行为是否符合预期。具体查什么查有没有意料之外的写操作——比如某个只读接口偷偷更新了一张表的时间戳查有没有漏掉WHERE条件的更新查有没有语句在循环里被调用了成百上千次N1 问题在 general log 里看得一清二楚查敏感字段有没有出现在查询条件里。聚合成语句模板看效果最好。把argument里的数字常量替换成占位符再分组能直接得到“这个模块总共发了多少种不同的 SQL”awk -F\t NF4 $3Query {print $4} general_trace.log \ | sed -E s/[0-9]/?/g \ | sort | uniq -c | sort -rn | head -30一个接口如果聚合出上百种不同的语句模板那基本可以判定它有问题要么是拼 SQL 的方式不对要么是查询逻辑本身有缺陷。这种审计在预发环境做成本几乎为零比上线之后靠慢日志和监控去猜要高效得多。5. 高频问题与排查实录5.1 开关打开了却看不到日志的五种原因这是被问得最多的一类问题我按出现频率排一下。第一种log_output是NONE。这个值的意思是“丢弃”日志开关开着但输出被关掉了表现就是什么都没发生。先查这个变量。第二种路径权限不对。MySQL 进程对这个目录没有写权限或者路径的上级目录不存在它打不开文件只在错误日志里留一行不会报错给客户端。查一下错误日志里有没有相关提示再看看数据目录的属主。第三种改完general_log_file没重新开关。前面说过改路径不会立即生效还在写老文件你以为新文件是空的就等于没开。第四种文件被logrotate改名了但没执行FLUSH GENERAL LOGSMySQL 还攥着旧句柄往改名后的文件里写你去tail新文件当然是空的。第五种会话执行过SET sql_log_off ON。这个连接自己的语句全被静音了。如果应用代码或者中间件里有这么一句表现就是全局开关正常但某个来源的日志永远缺失。5.2 性能与磁盘的坑怎么提前拦住性能这块要有个清醒认识general log 的开销不是“能不能接受”的问题而是“你的负载裕量够不够”的问题。低负载下开十分钟你基本感觉不到影响高并发写密集的场景下开五分钟响应时间就可能翻倍。我的判断标准是这样的如果实例的 CPU 平时就在 60% 以上或者磁盘的写入延迟已经开始抖动不要开日志改用其他手段比如从应用侧加 SQL 打印、用客户端抓包看协议或者干脆在从库上做采集。从库的开销不影响主业务链路这是一个很实用的规避办法。磁盘这块除了上面说的估算和轮转还有两个细节。一是文件系统和数据目录在同一个分区的时候日志把分区写满MySQL 会直接进入不可写状态所有写入全部失败这是生产事故级别的影响。所以采大流量的时候我会把general_log_file指到数据目录之外的独立挂载点即使写满也只影响日志本身。二是容器化环境下日志路径如果落在容器的可写层而不是挂载卷里容器一重启数据全丢还可能撑爆宿主机的存储配额这一点在编排配置里要特别确认。5.3 问题速查表把常见现象和对应动作整理成一张表出问题的时候照着对就行。现象最可能的原因处理动作开关为 ON 但无任何输出log_output NONE设为FILE或TABLE日志文件一直是 0 字节目录权限不足或路径不存在检查属主看错误日志改了文件路径还在写老文件未重新开关日志OFF再ON轮转后日志不再增长未执行FLUSH GENERAL LOGS执行该命令重新打开文件某个来源的语句完全不记录该会话设了sql_log_off会话内改回OFF查询mysql.general_log极慢CSV 引擎无索引关日志后转存并建索引无法TRUNCATE日志表日志处于开启状态先关日志再清空重启后日志自动又开了用了SET PERSISTRESET PERSIST或改回SET GLOBAL6. 几条踩出来的硬经验6.1 别把它当审计日志用我最想强调的一条general log 不是审计方案。它的定位是临时诊断工具不是长期记录设施。原因有三。一是它没有防篡改能力任何有文件读取权限的人都能改、能删取证意义有限。二是它没有完整性保证磁盘满了就停谁会注意到三是它的内容太杂里面混着大量驱动初始化语句和内部探针查询真做合规审计信噪比低到没法用。真要审计得上专门的审计组件或者应用层埋点那是另一套东西。把它定位成“现场快照”就对了出问题的时候开十分钟拿到现场立刻关掉分析完归档或删除。用完就收绝不长期开着。6.2 我常用的过滤套路原始日志不能直接看一定要先过一遍。我手上常备的三个命令覆盖八成场景。看命令类型分布先搞清楚这份日志里都是些什么awk -F\t NF3 $3! {print $3} general_trace.log \ | sort | uniq -c | sort -rn按线程号聚合找出话最多的连接awk -F\t NF4 $3! {print $2} general_trace.log \ | sort | uniq -c | sort -rn | head -20过滤掉驱动初始化噪音只看真正的业务语句awk -F\t NF4 $3Query $4 !~ /^(SET|SHOW)/ {print $4} \ general_trace.log | sort | uniq -c | sort -rn | head -40最后这条我几乎每次都用。SET和SHOW开头的语句在日志里占比极高滤掉之后剩下的才是你真正关心的东西。把数字常量替换成占位符之后同一类业务操作会聚到一起一眼就能看出哪条语句被反复调用了成千上万次——N1问题就是这么暴露出来的。6.3 一个减少干扰的实用技巧开启之前如果已知某些监控探针或者健康检查会持续发查询让它们的连接先把sql_log_off打开或者更简单把这类探针指向另一个不采集的实例。少一类噪音源分析时就少一层误判。另外采集窗口尽量短。十分钟足够复现绝大多数偶发问题一小时往往只是让日志文件变大、让分析变难。如果问题复现周期确实长用“定时开关”的方式比如每小时的整点开三十秒跑一天下来抓到八到十次快照比连续开二十四小时要划算得多磁盘压力和分析难度都小了一个数量级。这套用法我在几个不同负载特征的环境上都跑过短周期快照配合模板聚合抓问题的命中率比漫无目的长期开启高得多磁盘也从来没出过事。

MySQL general log通用查询日志：原理、配置与故障排查实战

相关推荐

2025技术趋势报告：AI、机器人、区块链等五大平台加速收敛

hindsight复盘体系：以决策审计对抗后见之明偏差

Sysmac Studio版本1安装配置全攻略：从系统兼容到在线连接验证

更多资讯

归一化RGB全解析：尺度归一化与色度归一化区别及图像预处理实战

Activiti6中文文档实战：工作流引擎配置、BPMN与二次开发

TensorFlow从安装到实战：2024年深度学习框架选型与避坑指南

美赛A题时序预测：混合模型与特征工程实战

Telegram验证码机制解析与安全实践

递归实现链表合并与反转：C++算法精解

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？