主从复制流量突增但延迟不涨，大概率是代理或应用直连从库读取、或从库被误写入；insert ... select 和 load data local infile 会绕过复制监控并放大负载。
MySQL主从复制流量突增但延迟不涨，SHOW SLAVE STATUS 看不出问题？
这种情况大概率是网络层或中间件在“悄悄转发”流量，比如代理（ProxySQL、MaxScale）或应用直连了从库做读请求，而监控只盯着复制线程本身。复制延迟低 ≠ 从库负载低，更不等于数据流向受控。
实操建议：
- 用
tcpdump抓取从库3306端口的入向流量，过滤非复制线程来源：tcpdump -i any port 3306 and not host [主库IP] - 检查
information_schema.PROCESSLIST中非system user的连接，重点关注Host字段是否大量来自应用服务器而非主库 - 确认是否有
read_only=OFF的从库被误写入，这类写入不会进复制流，但会污染数据一致性
用 pt-query-digest 分析慢日志时发现大量 INSERT ... SELECT，但业务没这么用？
迁移过程中常有人用 INSERT INTO t1 SELECT * FROM t2 类语句批量导数据，这类操作在源库记为一条语句，但在从库会放大成逐行写入，极易打满 IO 和复制线程。更麻烦的是，它不触发 binlog_row_image=FULL 的完整镜像，可能让基于行的复制丢失上下文。
实操建议：
- 在源库开启
binlog_rows_query_log_events=ON，让mysqlbinlog能还原原始语句，方便定位是谁在跑这类操作 - 检查
SHOW VARIABLES LIKE 'binlog_row_image'，迁移期间建议设为FULL，避免 UPDATE/DELETE 因缺失旧值导致从库校验失败 - 禁用从库的
sql_log_bin=0临时写入后，务必手动补 binlog 或跳过事件，否则后续 DDL 可能卡住
Wireshark 里看到大量 COM_QUERY 包含 LOAD DATA INFILE，但 MySQL 错误日志没报错？
LOAD DATA INFILE 在主从架构中默认被禁止（secure_file_priv 不同 + 从库 read_only），但如果客户端走的是 LOAD DATA LOCAL INFILE，它实际由客户端读文件、分片发 INSERT，服务端根本看不到“文件路径”，也就不会校验权限——这种行为绕过所有服务端管控，且无法被 binlog 完整记录。
实操建议：
- 在客户端连接参数中显式加
（JDBC）或禁用 <code>local_infile（MySQL CLI） - 用
mysqlbinlog --base64-output=DECODE-ROWS -v检查对应时间段 binlog，若只有零散 INSERT 而无原始 LOAD 命令，基本可锁定是 LOCAL 版本 - 迁移任务中统一改用
mysqldump --tab+mysqlimport，确保路径、权限、格式全程可控
Fluentd / Filebeat 收集 MySQL 日志后，字段 event_time 和 server_id 对不上时间线？
MySQL 的 general_log / slow_log 时间戳是语句开始执行时间，而 binlog event timestamp 是写入 binlog 缓冲区的时间，两者在高并发下可能差几十毫秒；更关键的是，server_id 在 relay log 里会被从库重写，原始 source server_id 仅保留在主库 binlog 中。
实操建议：
- 不要依赖日志采集工具自带的
@timestamp，必须提取 MySQL 日志行内的# Time:或# Query_time:字段做时间对齐 - 跨实例追踪时，用
SELECT @@server_id, @@hostname手动打标每个节点，别信配置文件里的注释 - 如果用
pt-heartbeat监控延迟，确保它的表建在mysql库下，否则某些代理会拦截跨库写入，造成假延迟
真正难的不是抓到哪条 SQL 在跑，而是确认它从哪来、经过了谁、有没有被改写、时间戳以谁为准——这些细节一漏，监控图就变成幻觉。
