慢查询日志不能防拖库但可发现早期痕迹，需调低long_query_time、启用min_examined_row_limit和log_queries_not_using_indexes，并结合实时监控与多源日志联动分析。
慢查询日志本身不防拖库，但它能帮你发现拖库行为的早期痕迹——比如攻击者用 SELECT * FROM user_info 配合大范围 WHERE 条件批量导出数据，这类操作往往响应慢、扫描行数多、无索引支持。光开日志没用，关键是怎么配、怎么看、怎么联动响应。
slow_query_log=ON 为什么查不到拖库语句？
默认 long_query_time=10，而拖库常用分页或 LIMIT 大偏移查询（如 SELECT * FROM orders LIMIT 100000, 1000），单次执行可能不到 10 秒，根本进不了慢日志。更麻烦的是，有些拖库用小批量高频请求绕过阈值，log_queries_not_using_indexes=ON 又只记“没走索引”，不区分意图。
- 必须把
long_query_time调低，建议设为0.5（500ms）甚至0.1，尤其对核心敏感表 - 配合
log_queries_not_using_indexes=ON，但要注意：它会对全表扫描的合法运维（如夜间统计）也告警，需结合时间窗口过滤 -
min_examined_row_limit=1000是个实用参数——只记录扫描行数超 1000 的语句，能直接捕获大多数拖库特征
mysqldumpslow 看不出异常，得换分析方式
mysqldumpslow 按平均耗时、出现次数聚合，会把分散的拖库请求“抹平”。比如攻击者每秒发一条 SELECT * FROM logs WHERE id > ? ORDER BY id LIMIT 100，每条都 300ms，mysqldumpslow 可能只显示“平均 300ms，共 200 次”，毫无威胁感。
- 直接用
tail -f实时盯slow_query_log_file，关注Rows_examined和sql_text中是否含SELECT *+ 大范围条件（如created_at > '2020-01-01'） - 用
awk提取高危模式：awk '/Rows_examined: [5-9][0-9]{4,}/ && /SELECT \*/' /var/lib/mysql/host-slow.log - 把慢日志接入 ELK 或 Loki，对
Rows_examined字段建监控看板，设置突增告警（如 5 分钟内同比涨 300%）
日志路径和编码问题导致监控断档
某些云厂商 RDS 控制台下载慢日志失败，报错类似 ascii codec can't decode byte，实际是日志里混入了客户端传来的非 ASCII 字符（如中文注释、用户昵称），Python 2 环境解析崩溃。结果就是你配好了，日志也在写，但控制台看不到、没法下载分析。
- 确认 MySQL 实例用的是 Python 3 环境（新镜像默认支持 UTF-8），老实例要升级 agent
- 临时规避：在
mysql_utils.py中注释掉日志脱敏相关行（如desensitize_ip_regx.sub(...)），避免解析中断 - 生产环境别依赖控制台下载，用
SELECT SLEEP(1)触发日志轮转后，直接scp拉取文件，或配置log_output='TABLE'写入mysql.slow_log表，用 SQL 查询更可控
慢查询日志只是第一道观察哨，真正卡住拖库得靠组合动作：它报警后，立刻检查 information_schema.PROCESSLIST 是否有长时间运行的 SELECT 连接，再结合审计日志确认该账号近期是否有异常登录或权限变更——单点配置再细，也挡不住绕过日志的直接文件窃取。
