智慧停车场小程序上线后，我们踩过的5个坑：从MySQL索引优化到uni-app分包实战

智慧停车场小程序性能优化实战：从数据库瓶颈到前端加载的5个关键解决方案

当我们的智慧停车场小程序用户量突破10万时，系统开始频繁出现响应延迟——管理员后台的车位状态刷新需要8秒，用户端的小程序首屏加载时间超过5秒，高峰期甚至出现支付超时。这不是简单的服务器扩容能解决的问题，而是一系列架构设计和技术选型留下的技术债务集中爆发。本文将分享我们如何通过系统性优化，将数据库查询速度提升20倍，小程序包体积缩减70%，并实现车位状态的秒级同步。

1. MySQL索引优化：从8秒到0.4秒的蜕变

在用户量激增后，最先崩溃的是数据库查询性能。特别是tc_bill表和tc_seat表，承担着高频的读写操作。我们通过EXPLAIN分析发现，最耗时的三条查询分别是：

-- 账单分页查询（平均执行时间3.2秒） SELECT * FROM tc_bill WHERE park_id=123 AND ispay='0' ORDER BY sts DESC LIMIT 10; -- 车位状态统计（平均执行时间4.8秒） SELECT COUNT(*) FROM tc_seat WHERE park_id=123 AND state='1'; -- 车辆历史记录查询（平均执行时间2.7秒） SELECT * FROM tc_bill WHERE cno='京A12345' ORDER BY sts DESC LIMIT 20;

1.1 复合索引设计与优化

针对上述查询，我们为关键表设计了新的索引策略：

特别注意：对于tc_seat表，我们移除了原本在state字段上的单列索引，因为测试发现：

-- 错误示例：单列索引会导致全表扫描 ALTER TABLE tc_seat ADD INDEX idx_state (state); -- 正确做法：使用park_id+state的复合索引 ALTER TABLE tc_seat ADD INDEX idx_park_state (park_id, state);

1.2 索引使用的常见陷阱

在优化过程中，我们发现了几个典型问题：

1. 过度索引：原系统在tc_bill表的cid、uid、park_id等字段上都建立了单列索引，导致写入性能下降30%
2. 无效索引：tc_seat表的note字段有索引但从未在查询中使用
3. 索引失效：使用LIKE '%京A%'查询车牌时无法利用索引

提示：定期使用SHOW INDEX FROM table_name和EXPLAIN分析索引使用情况，删除冗余索引

2. uni-app分包策略：首屏加载从5秒到1.5秒

随着功能迭代，小程序主包体积达到3.2MB，严重超出微信小程序推荐的2MB限制。我们采用的分包方案如下：

project ├── src │ ├── common # 公共代码 │ ├── pages # 主包页面 │ │ ├── index # 首页 │ │ └── user # 用户中心 │ └── subpackages # 分包目录 │ ├── parking # 停车场模块 │ │ ├── map # 车位地图 │ │ └── detail # 详情页 │ └── payment # 支付模块 │ ├── cashier # 收银台 │ └── history # 支付记录

关键配置项（pages.json）：

{ "pages": [...], "subPackages": [ { "root": "subpackages/parking", "pages": [ { "path": "map/index", "style": {...} }, {...} ] }, {...} ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["subpackages/parking"] } } }

2.1 分包效果对比

3. 车位状态实时同步方案选型

初期采用的传统轮询方案（每10秒请求一次）在高峰期导致服务器负载激增。我们对比了三种解决方案：

最终选择WebSocket方案，核心代码结构：

// 前端实现 const socket = new WebSocket('wss://yourdomain.com/ws'); socket.onmessage = (event) => { const data = JSON.parse(event.data); if (data.type === 'seat_update') { updateSeatStatus(data.seats); // 更新UI } }; // Spring Boot后端 @ServerEndpoint("/ws") @Component public class WebSocketEndpoint { @OnOpen public void onOpen(Session session) { // 新连接建立 } @OnMessage public void onMessage(String message, Session session) { // 处理客户端消息 } // 广播车位状态变化 public static void broadcastSeatUpdate(List<Seat> seats) { // 实现广播逻辑 } }

4. 高并发支付订单处理优化

在早晚高峰时段，支付成功率从平时的99%骤降至85%。通过分析发现瓶颈主要在：

1. 订单状态更新使用SELECT FOR UPDATE导致锁竞争
2. 支付回调处理没有幂等设计
3. 账单表tc_bill的ispay字段更新没有批量优化

优化后的支付流程：

// 优化后的支付核心逻辑 @Transactional public PaymentResult handlePayment(PaymentRequest request) { // 1. 使用乐观锁替代悲观锁 Bill bill = billMapper.selectById(request.getBillId()); if (bill.getIspay().equals("1")) { return PaymentResult.alreadyPaid(); } // 2. 支付处理（调用第三方支付接口） PaymentResponse response = paymentService.process(request); // 3. 更新订单状态（带版本校验） int updated = billMapper.updateBillStatus( bill.getId(), "1", bill.getVersion() ); if (updated == 0) { throw new ConcurrentUpdateException(); } // 4. 记录支付日志（幂等设计） paymentLogService.logPayment( response.getTransactionId(), request, response ); return PaymentResult.success(response); }

关键优化点：

• 支付结果回调接口增加transaction_id幂等校验
• 将tc_bill表的price和paymoney字段从DECIMAL(10,2)改为INT存储分单位
• 为高频查询添加covering index：

ALTER TABLE tc_bill ADD INDEX idx_bill_cover (id, park_id, ispay, sts, ets, hours);

5. 性能监控与持续优化体系

建立完整的性能监控体系比单次优化更重要。我们部署了以下系统：

1. 数据库监控：

   • 慢查询日志（超过500ms）实时告警
   • 使用Prometheus+Grafana监控QPS、连接数等指标

2. 小程序性能监控：

   // 在app.vue中收集性能数据 export default { onLaunch() { const report = (metric) => { wx.request({ url: '/monitor', data: { metric } }); }; // 上报关键指标 report({ type: 'launch_time', value: performance.now() }); } }

3. 压力测试方案：

   # 使用wrk模拟高峰流量 wrk -t12 -c400 -d60s --latency \ "https://api.example.com/parking/status?park_id=123"

优化永无止境。最近我们正在试验将tc_seat表的状态数据迁移到Redis，初步测试显示查询延迟从120ms降至8ms。技术选型没有银弹，只有持续测量、验证和迭代，才能构建真正经得起考验的系统。