MySQL开启general_log后看不到导入SQL的根本原因是其默认只记录客户端连接发起的语句，而source或mysqldump等批量导入操作可能绕过常规日志路径；需确认general_log和log_output均启用、输出目标可访问，且导入命令实际将语句交由服务器执行。
MySQL 开启 general_log 后看不到导入时的 SQL
根本原因是 general_log 默认只记录客户端连接发起的语句，而像 mysql 命令行工具执行 source、或 mysqldump 导入时用的批量协议（如 load data infile 或二进制协议），部分语句可能不走常规查询日志路径；更常见的是日志输出目标设为 table 但没查对表，或日志开关没真正生效。
实操建议：
- 先确认日志是否真开启：
SELECT @@global.general_log;和SELECT @@global.log_output;必须同时为ON和'TABLE'（或'FILE'） - 如果
log_output = 'TABLE'，查日志必须用：SELECT * FROM mysql.general_log ORDER BY event_time DESC LIMIT 20;—— 注意是mysql库下的general_log表，不是当前库 - 若用
'FILE'模式，需确认general_log_file路径可写，且 MySQL 进程有权限写入（常见坑：SELinux 或容器内路径挂载问题） - 导入时用
mysql -u root -p 方式，语句会正常记录；但用 <code>source dump.sql在已连接会话中执行，某些 MySQL 版本（如 5.7）可能不记录注释和空行后的首条语句
导出大文件时 general_log 文件爆炸性增长
general_log 是全量记录，一条 INSERT 变成一行日志，一个含 10 万行的 INSERT … VALUES 就生成 10 万行日志。它不压缩、不轮转，极易撑爆磁盘或拖慢导入速度。
实操建议：
- 导入前临时开启：
SET GLOBAL general_log = ON;，导入完立刻关：SET GLOBAL general_log = OFF;（注意：需要 SUPER 权限） - 避免在生产环境长期开启；调试完务必关闭，否则后续所有查询都会写日志
- 若必须保留日志，优先选
TABLE输出而非FILE，方便用 SQL 截取时间段：WHERE event_time BETWEEN '2024-06-01 10:00:00' AND '2024-06-01 10:05:00' - 不要依赖
general_log做性能分析——它开销大、无执行时间、无执行计划，真要分析用slow_query_log+long_query_time=0更靠谱
docker 或云数据库里根本找不到 general_log 文件
容器默认不挂载日志目录，阿里云 RDS、腾讯云 CDB 等托管服务直接禁用 general_log 的 FILE 输出，甚至部分版本连 TABLE 输出都阉割了——这是权限和架构限制，不是配置错了。
实操建议：
- docker run 时加参数：
-v /host/log:/var/lib/mysql-files，并确保general_log_file指向该路径下可写文件（如/var/lib/mysql-files/general.log） - 云数据库请直接放弃 FILE 模式；改用
log_output='TABLE'，但先查文档确认是否支持（例如 AWS RDS MySQL 5.7+ 支持，但 Aurora 可能不支持） - 若云平台明确禁用，唯一办法是改用客户端抓包：用
tcpdump -i lo port 3306 -w mysql.pcap，再用 Wireshark 过滤 MySQL 协议（仅限本地测试环境）
看到日志但关键 INSERT 没出现，怀疑被过滤了
general_log 不过滤语句，但有两个隐形“消失”场景：一是语句被优化器重写（如视图展开、子查询上拉），记录的是最终执行形态；二是多语句模式下，客户端未启用 CLIENT_MULTI_STATEMENTS 标志（如老版本 PHP mysqli），会导致分号分隔的多条语句只记第一条。
实操建议：
- 检查导入命令是否带
--force或-f：出错时默认停止，后续语句根本不会执行，自然不记录 - 对比
mysql客户端版本和服务器版本，5.6 以前对多语句支持不一致，建议统一用 5.7+ 客户端 - 临时换用
mysql --verbose -u root -p &1 | grep -E "^(INSERT|UPDATE|DELETE)"，从客户端 stdout 抓原始语句（前提是 dump 文件不含 /* */ 注释干扰） - 如果 dump 文件含大量
INSERT INTO ... SELECT，注意general_log记录的是完整语句，但可能因长度截断（由max_allowed_packet影响），查mysql.general_log表时用LENGTH(argument)看是否被截
真正麻烦的不是开不开日志，而是你得同时盯住三个地方：MySQL 的 global 变量状态、日志输出目标的可访问性、以及导入命令本身是否真的把语句交给了服务器执行——少一个环节，日志就断在半路。
