3. 慢查询定义与标准：本次复盘采用的慢查询阈值、判定标准、监控指标
在《Go权限审计网关慢查询复盘》中，明确“什么是慢查询”是后续所有根因分析、优化方案和效果评估的基础。如果定义模糊，优化就会失去靶心。本章将严格定义本次复盘所使用的慢查询阈值、判定标准以及核心监控指标，确保团队对“慢”的认知完全对齐。
3.1 慢查询阈值：分层定义，避免“一刀切”
权限审计网关的请求路径包含多个环节：网络传输、网关路由、认证鉴权、审计日志写入、后端服务响应。不同环节的耗时量级差异巨大，因此我们采用分层阈值策略，而非单一固定值。
| 层级 | 指标名称 | 慢查询阈值（P99） | 说明 |
|---|---|---|---|
| L1 网关层 | 网关总耗时 | > 500ms | 从请求进入网关到响应返回客户端的完整耗时 |
| L2 鉴权层 | 鉴权逻辑耗时 | > 200ms | Token 解析、权限校验、策略匹配等核心鉴权操作 |
| L3 审计层 | 审计日志写入耗时 | > 100ms | 审计日志的序列化、缓冲、异步写入数据库或消息队列 |
| L4 数据层 | 数据库查询耗时 | > 50ms | 针对 MySQL/PostgreSQL 的单次 SQL 查询或事务 |
| L5 外部依赖 | 下游服务调用耗时 | > 300ms | 调用用户中心、策略中心等外部 gRPC/HTTP 服务 |
阈值设定原则： 基于生产环境过去 30 天的 P99 耗时数据，结合业务容忍度（SLA 要求 99.9% 的请求在 1s 内完成），将各层 P99 阈值的 1.5 倍作为慢查询判定线。例如，数据库查询 P99 为 35ms，则阈值设为 50ms，留出一定缓冲。
3.2 判定标准：多维度综合判定，减少误报
单一维度的耗时超标并不一定代表“慢查询”需要被复盘。我们采用三维度综合判定模型，只有当请求同时满足以下三个条件时，才被标记为一次“慢查询事件”：
- 耗时维度： 任意一层级的耗时超过对应阈值（见 3.1 节表格）。
- 频率维度： 在 1 分钟的时间窗口内，同一接口（或同一 SQL 模版）的慢查询次数 >= 5 次，排除偶发抖动。
- 影响维度： 该慢查询导致客户端超时（HTTP 504/408）或触发网关熔断降级。
避坑提示： 仅依赖耗时维度容易产生大量“噪音”。例如，某次数据库查询因行锁等待耗时 200ms，但后续请求正常，这种偶发情况不应纳入复盘范围。加入频率和影响维度后，能有效聚焦于真正影响系统稳定性的慢查询。
3.3 监控指标：全链路可观测性数据采集
为了支撑上述判定标准，我们建立了覆盖网关、应用、数据库三个层面的监控指标体系。所有指标均通过 Prometheus + Grafana 进行采集和可视化。
3.3.1 核心指标清单
| 指标分类 | 指标名称 | 指标类型 | 采集方式 |
|---|---|---|---|
| 网关层 | gateway_request_duration_seconds | Histogram | Go 中间件埋点 |
| 网关层 | gateway_upstream_rtt_seconds | Gauge | Envoy/网关主动探测 |
| 鉴权层 | auth_check_duration_seconds | Histogram | Go 业务代码埋点 |
| 审计层 | audit_log_write_duration_seconds | Histogram | Go 业务代码埋点 |
| 数据层 | db_query_duration_seconds | Histogram | GORM/数据库驱动 Hook |
| 数据层 | db_slow_queries_total | Counter | MySQL slow_query_log 解析 |
| 数据层 | db_connection_pool_wait_seconds | Gauge | 数据库连接池指标 |
| 业务层 | request_slow_event_total | Counter | 综合判定后的事件计数 |
3.3.2 慢查询判定流程（SVG 图）
下图展示了从原始请求到最终“慢查询事件”标记的完整判定流程，帮助理解各监控指标如何协同工作。
3.4 慢查询日志规范：统一格式，便于自动化分析
所有被标记的慢查询事件，会以结构化 JSON 格式写入独立的慢查询日志文件（slow_query.log），与业务日志分离。日志字段设计如下：
{
"event_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"timestamp": "2025-03-15T14:23:10.123Z",
"gateway_latency_ms": 520,
"auth_latency_ms": 180,
"audit_latency_ms": 95,
"db_latency_ms": 45,
"upstream_latency_ms": 200,
"request_path": "/api/v1/permissions/check",
"http_method": "POST",
"user_id": "user_12345",
"client_ip": "10.0.1.100",
"slow_layer": "gateway",
"trigger_reason": "gateway_latency > 500ms && frequency >= 5 && timeout_occurred",
"db_slow_queries": [
{
"sql": "SELECT * FROM permissions WHERE user_id = ? AND resource_id = ?",
"duration_ms": 45,
"rows_examined": 15000,
"rows_sent": 10
}
]
}
关键设计点：
- slow_layer 字段直接标识出哪一层是主要瓶颈，方便快速定位。
- trigger_reason 字段记录了触发慢查询判定的具体原因，便于复盘时追溯判定逻辑。
- db_slow_queries 数组内嵌了具体的慢 SQL 信息，包括扫描行数和返回行数，为后续 SQL 优化提供直接依据。