远程 MySQL 下「附近球馆」接口从 5 秒优化至 300ms 实战
摘要Spring Boot 远程库场景里一次列表接口串行 4 次 SQL冷启动可达数秒。记录一次把 count 砍掉、改 JOIN 聚合、前端并行请求后的效果。正文Markdown可直接贴 CSDN远程 MySQL 下把「附近球馆」接口从 5 秒压到 300ms背景项目是约球小程序「快约球」后端 Spring Boot数据源在云上的 MySQL。「附近球馆」接口/api/v1/venue-sites/explore在 Network 里偶发5s同接口热请求大约80100ms。典型「冷慢热快」问题不只在 SQL 写法也在往返次数 × 远程 RTT。原请求在干什么一次explore首页 page0大致是count官方门店list官方门店每行还带场地数量 / 运动类型的关联子查询count共建 POIlist共建 POI前端为了兼容「有市码 仅区域关键词」两种数据还曾串行再打一遍explore。远程库单次 RTT 若按 200600ms 估四次串行很容易到秒级再叠加冷连接、缓冲池未热就会看到 5 秒那种尖刺。改动1. 首页少打 COUNT附近页固定page0size200列表长度已经够用不再为 total 单独 count。翻页路径才保留 count附近页几乎不走。2. 关联子查询改 JOIN 聚合原来每家门店(SELECTCOUNT(*)FROMvenue_courts...)AScourt_count,(SELECTGROUP_CONCAT(...)FROMvenue_courts...)ASsport_types改为对venue_courts先按site_id聚合再LEFT JOIN避免逐行相关子查询。3. WHERE 里去掉无意义的 TRIMTRIM(adm_city_code) ! 这类写法不利于走索引。改为adm_city_code IS NOT NULL AND adm_city_code ! 。4. 前端两次 explore 并行Promise.all([带 admCityCode 的请求, 仅 region 的请求])再在本地合并去重。总等待接近「较慢的那一次」而不是两次相加。5. Hikari 保一点热连接minimum-idle: 2减轻进程空闲后再建连的首包惩罚治标但远程库值得做。结果本机打同一接口冷请求约300ms热请求约80ms尖刺从「数秒」回到「可接受的远程延迟」。小结现象优先怀疑冷 5s / 热 100ms连接 多次 RTT而不只是缺索引列表接口先数「一次点击打了几趟库」前端连续 await改并行或合并接口独立开发把库放云上时本地感觉「偶发卡一下」用 Chrome Network 把慢请求的瀑布流截下来往往比先上缓存更管用。文末可加相关能力已用于「快约球」附近球馆列表。欢迎讨论远程库下的列表接口优化。
