4. 慢查询发现过程：APM告警、慢查询日志、DBA介入、根因定位

在支付核心链路的性能保障体系中，慢查询的发现与定位是数据库性能优化（DBP-Tuning）的第一道防线。本章复盘一次真实生产案例：某支付订单查询接口在晚高峰出现持续毛刺，TP99从50ms飙升至2.3s。我们按照“APM告警 → 慢查询日志 → DBA介入 → 根因定位”四步法，还原完整的排查链路。

4.1 第一步：APM告警——从业务指标到数据库指标的穿透

APM（Application Performance Monitoring）系统首先捕获到异常：pay_order_detail 接口的响应时间在20:00-20:05期间从50ms陡升至2.3s，错误率从0.1%升至3.2%。APM的数据库拓扑图自动关联出该接口对应的SQL模板，并标记为“疑似慢查询”。

APM的调用链追踪（Distributed Tracing）进一步定位到：该接口在一次请求中执行了两次相同的SQL查询，且第二次查询的数据库等待时间（DB Wait Time）占比高达82%。这提示我们：问题不在应用逻辑，而在数据库执行层。

4.2 第二步：慢查询日志——捕获“罪魁祸首”SQL

DBA登录数据库实例，开启 slow_query_log 并设置 long_query_time = 0.5（单位：秒），捕获到以下慢查询记录：

# Time: 2025-03-15T20:02:17.123456Z
# User@Host: pay_app[pay_app] @  [10.0.1.100]  Id: 45231
# Query_time: 1.852315  Lock_time: 0.000123  Rows_sent: 1  Rows_examined: 1587234
SET timestamp=1742061737;
SELECT
    o.id, o.order_no, o.amount, o.status, o.create_time,
    p.payment_id, p.pay_channel, p.pay_time,
    r.refund_id, r.refund_amount, r.refund_status
FROM pay_order o
LEFT JOIN pay_payment p ON o.id = p.order_id
LEFT JOIN pay_refund r ON o.id = r.order_id
WHERE o.user_id = 12345678
  AND o.status IN (2, 3, 5)
ORDER BY o.create_time DESC
LIMIT 20;

4.3 第三步：DBA介入——执行计划分析与索引诊断

DBA使用 EXPLAIN 分析该SQL的执行计划：

EXPLAIN SELECT
    o.id, o.order_no, o.amount, o.status, o.create_time,
    p.payment_id, p.pay_channel, p.pay_time,
    r.refund_id, r.refund_amount, r.refund_status
FROM pay_order o
LEFT JOIN pay_payment p ON o.id = p.order_id
LEFT JOIN pay_refund r ON o.id = r.order_id
WHERE o.user_id = 12345678
  AND o.status IN (2, 3, 5)
ORDER BY o.create_time DESC
LIMIT 20;

4.4 第四步：根因定位——索引缺失与SQL改写

结合执行计划与业务逻辑，DBA定位到两个根因：

1. 联合索引缺失： pay_order 表缺少 (user_id, status, create_time) 联合索引，导致无法同时利用 user_id 过滤、status 过滤和 create_time 排序。
2. SQL写法低效： LEFT JOIN 关联了 pay_payment 和 pay_refund 两张表，但业务场景只需要最近一笔支付和退款记录。全量关联导致驱动表扫描行数被放大。

优化方案：

-- 方案一：创建联合索引（推荐）
ALTER TABLE pay_order ADD INDEX idx_user_status_time (user_id, status, create_time DESC);

-- 方案二：SQL改写为子查询+JOIN，减少驱动表扫描
SELECT
    o.id, o.order_no, o.amount, o.status, o.create_time,
    p.payment_id, p.pay_channel, p.pay_time,
    r.refund_id, r.refund_amount, r.refund_status
FROM (
    SELECT id, order_no, amount, status, create_time
    FROM pay_order
    WHERE user_id = 12345678
      AND status IN (2, 3, 5)
    ORDER BY create_time DESC
    LIMIT 20
) o
LEFT JOIN pay_payment p ON o.id = p.order_id
LEFT JOIN pay_refund r ON o.id = r.order_id;

4.5 复盘要点总结