通用日志无法通过WHERE user_host LIKE '%IP%'精准过滤，因user_host为非结构化字符串（含空格、方括号、端口），且CSV引擎无索引，导致匹配不准确、性能差。
通用日志（general_log）是唯一能完整捕获客户端 IP + 每条语句组合的机制，但直接按 IP 过滤需依赖日志格式和输出方式——FILE 模式下靠文本解析，TABLE 模式下靠 user_host 字段提取，不能靠 WHERE 条件“精准匹配原始 IP”。
为什么不能直接用 WHERE user_host LIKE '%192.168.1.100%' 精确过滤？
MySQL 的 user_host 字段格式固定为 'user@host [IP]' 或 'user@host'（当 skip_name_resolve=ON 时才显示真实 IP）。即使启用了 skip_name_resolve，字段值仍含空格、方括号和可能的端口（如 'admin@192.168.1.100:54322'），导致简单 LIKE 匹配易漏或误中。
-
user_host是字符串，不是结构化字段，无法用正则做端口剥离 - 默认 CSV 引擎的
mysql.general_log表不支持索引，大数据量时LIKE '%192.168.1.100%'全表扫描极慢 - FILE 模式日志里 IP 出现在每行开头（如
# Time: 2026-05-08T10:22:33.123456Z\n# User@Host: root[root] @ 192.168.1.100 [192.168.1.100]），但中间有换行和空格，grep 需小心转义
FILE 模式下实时抓取某 IP 的全部操作（推荐调试用）
适用场景：快速确认某个异常连接干了什么，且 MySQL 已配置 log_output = FILE、general_log = ON，日志路径已知（如 /var/log/mysql/general.log）。
- 先确保
skip_name_resolve = ON在[mysqld]中，否则user_host显示的是主机名而非 IP - 用
tail -f实时监听，配合awk提取带目标 IP 的块（因每条语句前有# User@Host:行）：tail -f /var/log/mysql/general.log | awk '/# User@Host:.*\[192\.168\.1\.100\]/ {flag=1; next} /^$/ {flag=0} flag' - 注意：该命令会漏掉单行语句（无空行分隔时），更稳的方式是用
grep -A 1抓上下文：tail -f /var/log/mysql/general.log | grep -A 1 '\[192\.168\.1\.100\]'
- 别忘了加
sudo或切换到mysql用户执行，否则可能因权限读不到日志文件
TABLE 模式下查某 IP 的历史轨迹（适合短期回溯）
前提：已设 log_output = 'TABLE'，且没被自动清空（mysql.general_log 是 CSV 表，重启不丢，但磁盘满或手动删会消失）。
-
user_host字段内容示例：'root[root] @ 192.168.1.100 [192.168.1.100]'，所以匹配要覆盖方括号：SELECT event_time, argument FROM mysql.general_log WHERE user_host LIKE '%192.168.1.100%' AND command_type = 'Query' ORDER BY event_time;
- 如果想排除连接/断开等非 SQL 行，必须加
AND command_type = 'Query'，否则会混入Connect、Quit类型记录 - 字段
argument可能被截断（受max_allowed_packet限制），超长语句看不到完整内容 - 不建议在生产库上直接跑这个查询——CSV 表无索引，10 万行以上就明显卡顿
真正可靠的做法：用线程 ID（thread_id）反向锁定 IP 轨迹
通用日志本身不存线程 ID，但你可以先从 SHOW PROCESSLIST 或 performance_schema.threads 找到目标 IP 对应的当前 THREAD_ID，再结合其他日志（如错误日志或审计插件）交叉验证。不过对纯 general_log 而言，它只记录语句和 host，不记录 thread_id，所以“按线程过滤”在通用日志里实际不可行——这是常见误解。
- 有人误以为
mysql.general_log表有thread_id字段，其实没有；5.7+ 的 CSV 表只有event_time、user_host、thread_id（空）、server_id、command_type、argument六列，其中thread_id恒为空 - 若真需线程级追踪，得切到
performance_schema.events_statements_history（需提前开启 consumers），但它不保存 IP，只存USER和HOST（同user_host解析逻辑） - 最务实的路径：开
general_log→ 立即用SHOW PROCESSLIST记下可疑连接的ID→ 查日志时人工对照时间戳范围
真正难的不是“怎么写命令”，而是接受 general_log 的原始性：它不结构化、不索引、不压缩、不采样。你指望它像 ELK 那样查 IP 轨迹，就得自己补解析逻辑，或换用 audit_log 插件（但后者不记录原始 SQL）。生产环境里，这活儿通常交给外部代理层（如 ProxySQL 日志）或应用端埋点——数据库原生日志，只够临时兜底。
