4.7 数据与中间件观测：是数据库慢，还是等连接慢？

连接池 pending > 0  →  在排队（等窗口）
连接池 pending = 0 但查询耗时长  →  服务慢（厨师慢）

-- 前提：在 postgresql.conf 里加 shared_preload_libraries = 'pg_stat_statements'
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- 按总耗时排序（谁最消耗数据库时间）
SELECT
    calls,
    round(total_exec_time::numeric, 1)  AS total_ms,
    round(mean_exec_time::numeric, 2)   AS mean_ms,
    round((100 * total_exec_time / sum(total_exec_time) OVER ())::numeric, 1) AS pct,
    left(query, 70) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

SELECT
    pid,
    now() - query_start AS duration,
    state,
    wait_event_type,          -- ⭐ 关键：等待类型
    wait_event,               -- ⭐ 关键：具体在等什么
    left(query, 60) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

-- 谁在阻塞谁
SELECT
    blocked.pid       AS blocked_pid,
    blocked.query     AS blocked_query,
    blocking.pid      AS blocking_pid,
    blocking.query    AS blocking_query,
    now() - blocked.query_start AS blocked_duration
FROM pg_stat_activity blocked
JOIN pg_stat_activity blocking
  ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
WHERE cardinality(pg_blocking_pids(blocked.pid)) > 0;

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders WHERE status = 'PAID' ORDER BY created_at DESC LIMIT 20;

-- 在 postgresql.conf 里
-- shared_preload_libraries = 'auto_explain'
-- auto_explain.log_min_duration = '200ms'
-- auto_explain.log_analyze = on
-- auto_explain.log_buffers = on

curl -s localhost:8080/metrics | grep -E "db_pool_(active|idle|pending|total)"

pending > 0
    │
    ├─ 先查：单条 SQL 是不是很慢？（pg_stat_statements）
    │      └─ 是 → 优化 SQL / 加索引（不要先加池！）
    │
    ├─ 再查：事务范围是否过大？（长时间持有连接）
    │      └─ 是 → 缩小事务范围
    │
    └─ 都正常，仍是 pending > 0
           └─ 用 Little's Law 计算所需连接数（第 0 章 0.4 节）
              所需连接 = 目标 QPS × 单次查询耗时

目标：支撑 1000 QPS
单次查询平均耗时：20 ms
→ 平均所需连接 = 1000 × 0.020 = 20 个

但要用 P99 做悲观估计：
单次查询 P99：80 ms
→ 最坏情况下需要 = 1000 × 0.080 = 80 个

结论：池大小取 20~80 之间，配合「获取连接超时」保护。
      如果 80 个连接会让数据库受不了，说明查询需要优化，而不是池需要加大。

# ① 慢查询日志（超过阈值都记录）
redis-cli SLOWLOG GET 10

# ② 命令统计（哪些命令调用最多、最耗时）
redis-cli INFO commandstats

# ③ 延迟监控（记录超过阈值的延迟事件）
redis-cli LATENCY MONITOR 10
redis-cli LATENCY RESET
redis-cli LATENCY HISTORY event-name

redis-cli --bigkeys        # 扫描各类型最大的 key
redis-cli --hotkeys        # 需要 LFU 策略
redis-cli MEMORY USAGE <key>

现象：接口 P99 从 80ms 涨到 400ms，CPU 不高

① 看依赖级指标：dep.postgres 的 P99 涨了 → 问题在数据库方向
        ↓
② 看连接池：pending = 0，active = 8（池上限 10）
   → 没有排队，是【查询本身慢】
        ↓
③ 看 pg_stat_statements：某条查询 mean_exec_time 从 2ms 涨到 350ms
        ↓
④ EXPLAIN ANALYZE：发现 Seq Scan + Rows Removed by Filter: 90000
        ↓
⑤ 结论：缺索引 / 统计信息过期

如果第 ② 步是 pending = 18、active = 10（打满）
→ 结论改为【连接池排队】
→ 但要继续查：是查询变慢了（占用连接更久），还是并发上来了？
   → 前者优化 SQL，后者才考虑调池