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。
- 日志中显式记录影响行数（rowCount）：UPDATE返回0行可能意味着WHERE条件没匹配到，而非SQL慢
- 对分页查询，记录pageNum/pageSize和实际OFFSET值，便于识别深度分页陷阱（如OFFSET 1000000）
- 当APM发现某次调用SQL耗时异常，直接用TraceID查业务日志，快速确认是否同一请求还触发了缓存穿透、下游RPC重试、或重复提交
四、三者联动排查典型场景
例如：APM显示 /order/list 接口P95达3.2s，慢日志里有大量“SELECT * FROM order WHERE user_id=? ORDER BY create_time DESC LIMIT 20 OFFSET 10000”：
- 先看APM：该接口平均调用频次是否突增？Trace里是否有下游服务超时引发重试？
- 再查慢日志：相同SQL的Rows_examined是否从200飙升到20万？说明索引失效或数据倾斜
- 最后翻业务日志：对应TraceID下，是否出现“skip cache due to userId=-1”？暴露了非法参数导致绕过缓存直查DB
不复杂但容易忽略：监控不是堆指标，而是让APM、DB日志、业务日志说同一种语言——用TraceID锚定，用SQL指纹归类，用执行上下文还原现场。
