阿里云上的业务数据库，慢查询是最常见的性能问题之一，也最容易被忽略。页面卡顿、接口超时、CPU 居高不下，背后常常就是几条执行太久的 SQL。下面用一个订单列表的实际案例，说明怎么找到慢查询，以及怎么从指标上判断索引是否有问题。
问题背景：订单列表接口超时
某电商中台的订单列表接口，在大促预热期间平均响应时间从 200ms 涨到 3 秒以上，部分请求直接超时。应用侧监控显示数据库连接池长时间被占满，实例 CPU 已经接近 90%。
团队一开始以为是流量上来了、资源不够，先把实例规格扩了。效果只维持了很短一段时间，同样的症状很快又回来。扩容解决不了的问题，多半出在查询本身。
从慢日志找到问题 SQL
开启慢日志，按模板聚合
阿里云 RDS for MySQL 的慢日志可以在控制台设置 long_query_time 阈值，并查看明细。团队把阈值定在 1 秒，同时打开未使用索引的查询记录，这样没超时但没走索引的语句也会被记下来。
DAS 的性能洞察页支持按 SQL 模板聚合，能看到每类查询的执行次数、平均耗时、扫描行数和锁等待。原始慢日志里成千上万条 SQL，归并成几类模板之后，主要矛盾一眼就能看出来。
确认排名第一的查询
聚合后排在第一的查询占了总耗时 60% 以上，结构大致如下：
SELECT o.order_id, o.status, o.created_at, u.nickname
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'PAID'
AND o.created_at >= '2024-06-01'
ORDER BY o.created_at DESC
LIMIT 20 OFFSET 100000;问题有两层。OFFSET 很大时，数据库要先扫描并丢弃十万条记录，才能返回 20 条。另外，status 和 created_at 组合过滤，现有索引没法完整覆盖这个条件。
用执行计划核对判断
EXPLAIN 的结果显示，orders 表走的是 idx_status 单列索引，filtered 比例很低，之后还要通过 filesort 完成排序，扫描行数超过 80 万。优化器选的这条路径明显不划算。
执行计划给出的是估算值，不能只凭它下结论。在阿里云上，可以用 EXPLAIN ANALYZE（MySQL 8.0 支持）或 DAS 的 SQL 分析，核对实际耗时和扫描行数。两边对得上，判断才站得住。
索引和查询改写
建立复合索引
针对这个查询的过滤和排序方式，团队在 orders 表上建了一个联合索引：
ALTER TABLE orders
ADD INDEX idx_status_created (status, created_at);列顺序按照“等值条件在前，范围和排序在后”来排。status 是等值过滤，created_at 既做范围过滤又参与排序。这样优化器可以按索引顺序直接读数据，不再需要 filesort。
在阿里云 RDS 上做 DDL 时，优先用 DMS 的无锁变更或 Online DDL，并尽量放在业务低峰期。大表加索引仍然会带来 IO 和复制延迟的压力，执行前要先评估。
把深分页改成游标
索引只能缓解一部分问题。大 OFFSET 做的事情是跳过，再好的索引，被跳过的行也还是要读一遍。团队于是改用键集分页（keyset pagination）：
SELECT o.order_id, o.status, o.created_at, u.nickname
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'PAID'
AND o.created_at >= '2024-06-01'
AND (o.created_at, o.order_id) < ('2024-06-15 10:20:00', 987654)
ORDER BY o.created_at DESC, o.order_id DESC
LIMIT 20;前端每次请求带上上一页最后一条记录的 created_at 和 order_id，后端从这个位置往后读。翻到第几页，扫描行数基本一样，和页码无关。代价是不能任意跳页。对订单列表这种只看上一页、下一页的场景，这个取舍通常可以接受。
关联查询的取舍
users 通过主键关联，单次开销很小。但订单结果集变大之后，关联的次数也跟着变多。团队在应用层做了两处调整：先查订单主表拿到 ID 列表，再批量查询用户信息，同时减少不必要的 JOIN 字段读取。这一步要按实际数据量来权衡，不适合一刀切。
效果怎么验证
优化上线后，团队用同一套压测脚本做了前后对比：
- 订单列表接口 P99 响应时间从约 3.2 秒降到 180 毫秒左右
- 该类 SQL 的单次扫描行数从超过 80 万降到数百行量级
- 数据库 CPU 峰值从接近 90% 回落到 40% 左右
- 连接池等待基本消失，接口超时告警归零
这些数字来自这个业务和这套数据规模，别的环境结果会有差异。比数字更重要的是对比方法：优化前后要用同一数据集、同样的并发量，结果才有可比性。
怎么避免问题反复出现
单次优化只能处理眼前的问题。想让慢查询不再反复出现，可以从下面几处入手：
- 开发阶段接入 SQL 审核（DMS 或内部审核工具），对没有索引条件、深分页、全表扫描这类写法给出提醒，在提交前就拦住。
- 给关键业务表设置慢查询告警，阈值对齐接口的 SLA。只盯数据库整体负载，发现问题时往往已经晚了。
- 定期做索引巡检，找出长期未被使用的索引并清理。每多一个索引，写入成本也跟着增加，写入耗时的变化要一起看。
- 发布流程里加入性能回归，用预估数据量跑一遍新增查询，确认耗时可接受后再上线。
阿里云的慢日志、性能洞察、SQL 审核和无锁变更，基本覆盖了从发现到修复的主要环节。工具用得上，前提是先搞清楚业务的查询模式。
