SQL应用慢查询如何监控_APM与日志结合分析【教学】

SQL慢查询监控需融合APM、数据库慢日志与业务日志：APM捕获真实执行上下文并拆解耗时，慢日志记录执行计划与统计，业务日志串联请求生命周期，三者通过TraceID联动定位根因。

SQL慢查询监控不能只靠数据库自带的慢日志，必须结合APM（应用性能监控）和业务日志，才能准确定位“为什么慢”——是SQL写法问题、索引缺失、数据量突增，还是上游调用链拖累、连接池打满、或事务卡在某个服务环节。

一、APM中抓取真实SQL执行上下文

APM工具（如SkyWalking、Pinpoint、Datadog APM）能捕获应用层发起的SQL语句，并关联到具体HTTP接口、用户ID、TraceID和耗时。关键不是看“哪条SQL慢”，而是看“谁在什么场景下触发了它”。

• 开启SQL参数脱敏但保留结构：避免敏感信息泄露，同时保留WHERE条件字段、IN列表长度、LIMIT值等关键特征
• 标记高风险模式：自动识别SELECT *、未走索引的LIKE '%xxx'、大表JOIN无ON条件、子查询嵌套过深等
• 关联调用栈：一条耗时800ms的UPDATE，可能700ms花在等待数据库连接，而非执行本身——APM能拆出DB等待时间 vs 执行时间

二、数据库慢日志要带完整执行计划与统计

MySQL slow_log 或 PostgreSQL log_min_duration_statement 只是起点。必须确保日志包含：实际执行时间、扫描行数、返回行数、是否用到临时表/文件排序、是否触发全表扫描。

• MySQL建议开启：log_queries_not_using_indexes=ON + long_query_time=0.5（非仅1s），配合pt-query-digest定期分析
• PostgreSQL需配置：log_min_duration_statement = 500 + log_statement = 'mod'（记录DML）+ log_analyze = ON（带EXPLAIN ANALYZE输出）
• 注意：慢日志里的“执行时间”是数据库内核视角，不含网络传输、连接建立、应用解析结果时间——这正是APM补足的部分

三、业务日志串联请求生命周期

在DAO层或MyBatis拦截器中，以统一格式打印SQL摘要（如"UserDao.updateStatus: uid=123, status=2, cost=782ms"），并带上TraceID。

标签： mysql 工具 栈 ai sql语句 cos 为什么