# 慢查询分析服务

## 概述

慢查询分析服务采用**混合处理架构**，结合 Athena SQL 和本地 Go 代码的优势：

- **Athena 粗筛选**：在云端过滤掉 80% 的无关数据，减少数据传输
- **本地精细处理**：在 Go 中应用所有复杂规则，保持逻辑清晰易维护

## 架构设计

```
┌─────────────┐
│   Client    │
└──────┬──────┘
       │ POST /slowquery/analyze
       ↓
┌─────────────────────────────────────┐
│  SlowQueryAnalyzer                  │
│  ┌───────────────────────────────┐  │
│  │ 1. 构建粗筛选 SQL              │  │
│  │    - 排除不需要的 SQL          │  │
│  │    - 基础 Pattern 匹配         │  │
│  └───────────────────────────────┘  │
└──────────────┬──────────────────────┘
               │
               ↓ (调用 DataProxy)
┌─────────────────────────────────────┐
│  DataProxyService                   │
│  ┌───────────────────────────────┐  │
│  │ 2. 执行 Athena 查询            │  │
│  │    - 自动表管理                │  │
│  │    - 分区缓存                  │  │
│  └───────────────────────────────┘  │
└──────────────┬──────────────────────┘
               │
               ↓ (返回 10-20% 数据)
         ┌──────────┐
         │  Athena  │
         └──────────┘
               │
               ↓
┌─────────────────────────────────────┐
│  本地精细处理                        │
│  ┌───────────────────────────────┐  │
│  │ 3. 遍历每条记录                │  │
│  │ 4. 应用所有 Pattern 规则        │  │
│  │    - hasTableFullScan()        │  │
│  │    - hasIndexFullScan()        │  │
│  │    - hasCopTaskNumGt100()      │  │
│  │    - DeepOffset 检测            │  │
│  │    - StatsMissing 检测          │  │
│  └───────────────────────────────┘  │
└──────────────┬──────────────────────┘
               │
               ↓ (返回分析结果)
         ┌──────────┐
         │  Client  │
         └──────────┘
```

## API 接口

### POST /slowquery/analyze

分析指定时间范围内的慢查询，返回匹配的 Pattern。

**请求体：**

```json
{
  "start_date": "20251230",
  "end_date": "20251231",
  "data_source": "s3://o11y-prod-shared-ap-southeast-1/deltalake/1372813089209238420/11e824de-880e-4d20-8883-7a90e1b52d0e/slowlogs",
  "region": "ap-southeast-1"
}
```

**响应：**

```json
{
  "total_scanned": 1000,
  "filtered_count": 150,
  "pattern_count": 45,
  "patterns": [
    {
      "date": "20251231",
      "digest": "8cb1c13abaa0f693aeb0627e6d00c682ed0b512a21bfcc6d4b339e3ae2e3a7b0",
      "query": "SELECT * FROM t_showcase_task_record WHERE ...",
      "pattern_name": "TableFullScan",
      "pattern_name_sub": "",
      "query_time": 1.02,
      "mem_max": 350
    },
    {
      "date": "20251231",
      "digest": "abc123...",
      "query": "SELECT * FROM orders OFFSET 200000",
      "pattern_name": "DeepOffset",
      "query_time": 5.3,
      "mem_max": 1024
    }
  ],
  "statistics": {
    "TableFullScan": 12,
    "IndexFullScan": 8,
    "HugeResourceUsage": 15,
    "DeepOffset": 5,
    "StatsMissing": 3,
    "SendResponseSlow": 2
  }
}
```

## 支持的 Pattern 规则

### 1. HugeResourceUsage（资源占用过高）
- **条件 1**: `Mem_max > 5G`
- **条件 2**: `Query_time - Write_sql_response_total > 5s`
  - 如果延迟 > 40s，则 `pattern_name_sub = "Latency"`

### 2. Failed（查询失败）
- **条件**: `Succ = false`

### 3. TableFullScan（全表扫描）
- **条件**: 递归查找执行计划中的 `TableFullScan_xxx` 节点
- **额外条件**:
  - `estRows > 100,000`
  - `storeType != "tiflash"`

### 4. IndexFullScan（索引全扫描）
- **条件**: 递归查找执行计划中的 `IndexFullScan_xxx` 节点
- **额外条件**:
  - `estRows > 100,000`
  - `storeType != "tiflash"`

### 5. DeepOffset（深度分页）
- **条件**: SQL 包含 `OFFSET` 且数值 > 100,000

### 6. ExcessiveCopTask（过多 Cop Task）
- **条件**: 执行计划中 `cop_task.num > 100`

### 7. StatsMissing（统计信息缺失）
- **条件**: `Stats` 字段包含 "missing"

### 8. TiflashScanRegionImbalance（TiFlash 扫描不均衡）
- **条件**: 执行计划中 `region_balance > 10`

### 9. SendResponseSlow（响应返回慢）
- **条件**: `Write_sql_response_total > 10s`

## 粗筛选规则（Athena）

在 Athena 中先过滤掉以下 SQL：

### 排除规则
1. ❌ 包含 `read_from_storage(tiflash` 但不是 hint 的 SQL
2. ❌ 包含 `force index` 的 SQL
3. ❌ 以 `ANALYZE` 开头的 SQL
4. ❌ DDL 语句（CREATE, ALTER, DROP, TRUNCATE, RENAME）
5. ❌ 不以 `SELECT` 开头的 SQL

### 包含规则（至少满足一个）
1. ✅ `Mem_max > 5G`
2. ✅ `Query_time - Write_sql_response_total > 5s`
3. ✅ `Succ = false`
4. ✅ JSON 中包含 `TableFullScan_`
5. ✅ JSON 中包含 `IndexFullScan_`
6. ✅ SQL 包含 `OFFSET >= 100000`
7. ✅ JSON 中包含 `cop_task`
8. ✅ `Stats` 包含 "missing"
9. ✅ `Write_sql_response_total > 10s`

## 使用示例

### 示例 1：分析最近 2 天的慢查询

```bash
curl -X POST http://127.0.0.1:8087/slowquery/analyze \
  -H 'Content-Type: application/json' \
  -d '{
    "start_date": "20251230",
    "end_date": "20251231",
    "data_source": "s3://o11y-prod-shared-ap-southeast-1/deltalake/1372813089209238420/11e824de-880e-4d20-8883-7a90e1b52d0e/slowlogs",
    "region": "ap-southeast-1"
  }'
```

### 示例 2：查看 TableFullScan 的具体 SQL

```bash
curl -X POST http://127.0.0.1:8087/slowquery/analyze \
  -H 'Content-Type: application/json' \
  -d '{
    "start_date": "20260101",
    "end_date": "20260103",
    "data_source": "s3://...",
    "region": "ap-southeast-1"
  }' | jq '.patterns[] | select(.pattern_name == "TableFullScan")'
```

## 性能优化

### 数据量对比

| 处理阶段 | 数据量 | 说明 |
|---------|--------|------|
| Athena 扫描 | 100% (1000 条) | 扫描所有分区数据 |
| 粗筛选后 | ~15% (150 条) | 在 Athena 中过滤掉 85% |
| 精细处理后 | ~4.5% (45 条) | 最终匹配的 Pattern |

### 性能对比

| 方案 | Athena 扫描量 | 数据传输量 | 本地处理量 | 总耗时 |
|-----|--------------|-----------|-----------|--------|
| 纯 Athena SQL | 100% | 5% | 0% | 慢（SQL 复杂） |
| 纯本地处理 | 100% | 100% | 100% | 慢（传输大） |
| **混合方案** | **100%** | **15%** | **15%** | **快** |

### 优势
1. ✅ **减少数据传输**：只传输 15% 的数据
2. ✅ **逻辑清晰**：复杂规则在 Go 中实现，易维护
3. ✅ **精确匹配**：递归逻辑可以完全复用现有代码
4. ✅ **易于扩展**：新增规则只需修改 Go 代码

## 与现有代码对比

### 现有 S3 文件解析方式
```go
// 读取 S3 文件 -> 逐行解析 JSON -> 应用规则
parser.ParseS3File("s3://bucket/path/file.json")
```

### 新的 Athena 分析方式
```go
// Athena 粗筛选 -> 返回结果 -> 应用规则
analyzer.Analyze(ctx, &AnalyzeRequest{...})
```

### 优势对比

| 特性 | S3 文件解析 | Athena 分析 |
|-----|-----------|------------|
| 数据筛选 | 需要读取完整文件 | Athena 预筛选 |
| 分区支持 | 手动处理 | 自动分区剪枝 |
| 并发处理 | 单文件串行 | Athena 分布式 |
| 表结构变更 | 需要更新代码 | 自动表管理 |
| 成本 | S3 GET 请求 | Athena 扫描 + 压缩 |

## 总结

混合方案是最优选择：
- ✅ 利用 Athena 的分布式计算能力做粗筛选
- ✅ 利用 Go 代码的灵活性做精细处理
- ✅ 减少数据传输量，提升性能
- ✅ 逻辑清晰，易于维护和扩展
