技术深度剖析服务，帮你全面看清项目技术全貌。从需求、架构到性…

# 订单系统QPS瓶颈分析与改造方案

一、瓶颈定位（800 QPS压测数据）

• 连接池耗尽：HikariCP默认10连接，800 QPS × 0.2s并发需求≈160连接，实际排队等待占总耗时70%
• 慢SQL：SELECT * FROM order WHERE user_id=? AND status=? ORDER BY create_time DESC执行计划显示 type=ALL全表扫描，扫描120万行
• 单表膨胀：order表1800万行，未分库分表，buffer pool命中率降至92%
• 无缓存：商品/用户热点数据每次打库

二、索引优化（即时生效）

问题：现有索引 idx_user(user_id)，需回表后再过滤status+排序，Using filesort。

改造：

```sql

-- 联合索引：等值列在前，排序列在后

ALTER TABLE t_order

ADD INDEX idx_uid_status_ctime(user_id, status, create_time DESC),

ADD INDEX idx_ctime(create_time) FOR查询台订单列表;

-- SQL改为覆盖索引避免回表

SELECT id,user_id,amount,create_time FROM t_order

WHERE user_id=? AND status=? ORDER BY create_time DESC LIMIT 20;

```

预期：扫描行数120万→20，单次查询80ms→3ms。

三、分步改造路线（4周）

| 周期 | 动作 | 预期效果 |

|---|---|---|

| W1 | HikariCP调至maximumPoolSize=50；加Druid监控定位慢SQL | 排队延迟消除 |

| W2 | 上述索引重建+SQL改写；开启innodb_buffer_pool_size至物理内存70% | P99从2s→300ms |

| W3 | 引入Redis缓存商品详情（TTL 30min+空值缓存防穿透）、用户信息；接口加本地Caffeine一级缓存 | DB QPS降60% |

| W4 | 读写分离（ShardingSphere-JDBC，写主读从）；订单表按user_id分16片+按月归档历史数据至冷表 | 支撑3000+ QPS |

四、验证指标

• 压测目标：QPS 2000时P99 < 300ms，DB活跃连接<30
• 监控：Prometheus+Grafana看板（接口RT/连接池/慢SQL数），上线后灰度10%流量观察24h再全量