7.9 Lab 7：优化 Lab 6 找到的瓶颈

① /slow-db → 批量查询（② 级，收益极高，代价极低）
② /slow-cpu → Regex 提到顶层（② 级，收益高，代价极低）
③ /slow-io → 切到 Dispatchers.IO（③ 级，收益高，代价低）
④ （评估）给 /slow-db 加缓存 → 可能被否决

// before
get("/slow-db") {
    val ids = (1L..100L).map { (it * 7919) % 100_000 + 1 }
    val urls = ids.map { id ->                          // 100 次查询
        ds.connection.use { c -> /* 单条查询 */ }
    }
    call.respondText(urls.filterNotNull().joinToString("\n"))
}

// after
get("/slow-db") {
    val ids = (1L..100L).map { (it * 7919) % 100_000 + 1 }
    val urls = ds.connection.use { c ->                 // 1 次查询
        c.prepareStatement("select id, url from orders where id = any(?)").use { ps ->
            ps.setArray(1, c.createArrayOf("bigint", ids.toTypedArray()))
            ps.executeQuery().use { rs ->
                buildMap { while (rs.next()) put(rs.getLong(1), rs.getString(2)) }
            }
        }
    }
    call.respondText(ids.mapNotNull { urls[it] }.joinToString("\n"))
}

### 优化 1：消除 N+1

#### 提升多少
| 指标 | before | after | 变化 |
| --- | --- | --- | --- |
| P50 | | | |
| P99 | | | |
| DB 查询次数/请求 | 100 | 1 | -99% |

（跑 3 轮，取中位数；与噪声底线对比）

#### 代价
- （几乎没有代价——这是"减少工作"类优化的特点）

#### 回归验证
- [ ] 功能：返回的 url 列表与 before 一致（逐条比对）
- [ ] 性能：其他接口无退化
- [ ] 长稳：30 分钟浸泡无异常

// before
get("/slow-cpu") {
    val text = "x".repeat(20_000)
    var hits = 0
    repeat(200) {
        val re = Regex("""\d{3}-\d{4}""")     // ❌ 每次编译
        hits += re.findAll(text).count()
    }
    call.respondText("hits=$hits")
}

// after
private val PHONE_RE = Regex("""\d{3}-\d{4}""")   // 只编译一次

get("/slow-cpu") {
    val text = "x".repeat(20_000)
    var hits = 0
    repeat(200) {
        hits += PHONE_RE.findAll(text).count()
    }
    call.respondText("hits=$hits")
}

// before
get("/slow-io") {
    val n = ds.connection.use { /* JDBC — 阻塞 */ }
    call.respondText("n=$n")
}

// after
get("/slow-io") {
    val n = withContext(Dispatchers.IO) {       // ✅ 切到 IO
        ds.connection.use { /* JDBC */ }
    }
    call.respondText("n=$n")
}

// 更好：再加信号量限制并发
private val dbLimiter = Semaphore(64)
get("/slow-io") {
    val n = dbLimiter.withPermit {
        withContext(Dispatchers.IO) { ds.connection.use { /* JDBC */ } }
    }
    call.respondText("n=$n")
}

# 优化前后：在压 /slow-io 的同时，测 /normal 的延迟
# before: /normal 的 P99 会被拖到几百毫秒
# after:  /normal 的 P99 应该保持稳定（几十毫秒）

### 被否决的方案：给 /slow-db 加 Redis 缓存

**预期收益**：P50 可能下降 50%–70%

**否决理由**：
1. **收益不确定**：批量查询已经消除了 N+1（P99 从 400ms 降到 45ms），
   缓存的边际收益有限；
2. **命中率预估低**：如果 key 分散（每个订单只被查一次），缓存命中率会很低，
   而 P99 不会改善（第 7.4 节的数学原理：要让 P99 改善，命中率需 > 99%）；
3. **引入一致性与运维成本**：新增 Redis 依赖、失效逻辑、故障降级路径；
4. **掩盖问题**：这类优化会让人以为"查询已经很快了"，
   而实际上批量查询才是根本解法。

**重新评估的条件**：
- 如果这个接口变成读多写少且热点集中（命中率可 > 90%）
- 或者数据量增长导致即使批量查询也变慢