适合拆分的三类复杂查询：①多业务维度聚合查询；②含高成本子查询或窗口函数的报表类查询；③读多写少的中间态结果。拆分需按稳定维度、事实表分片、应用层组装三层解耦逻辑，并配套监控。
SQL复杂查询执行慢，核心原因是单次查询负载过高——涉及多表关联、聚合计算、全表扫描或缺乏有效索引。单纯优化SQL往往收效有限，而“拆分查询 + 缓存”是一种更务实、可落地的协同优化策略：用拆分降低单次数据库压力，用缓存拦截重复计算与高频读取。
哪些复杂查询适合拆分？
不是所有慢查询都该拆分。重点关注以下三类：
多业务维度聚合查询
：例如“统计每个城市、每个品类、每小时的订单量+GMV+用户数”，本应由应用层组合多个轻量查询完成，而非强求一条SQL输出全部结果。
带高成本子查询或窗口函数的报表类查询
：如含
且数据量大，可先查主表ID，再分批查详情并本地排序。
读多写少的中间态结果
：比如用户画像标签宽表、实时库存汇总视图，本身不常更新，但被多个接口高频调用。
怎么合理拆分？关键在“解耦逻辑”而非“简单切表”
拆分不是把一个JOIN语句硬拆成N条SELECT，而是按数据依赖关系和更新频率分层：
第一层：分离稳定维度
——城市、品类、用户基础属性等变化极少，优先查缓存（如Redis哈希）或本地配置，避免每次连库。
第二层：按主键/时间范围分片查事实表
——例如按天查订单明细，再合并统计；或按用户ID段并发拉取行为日志，比全表SUM更快。
第三层：应用层组装与计算
——把数据库的JOIN、GROUP BY、CASE WHEN等移到代码中做轻量聚合（如用HashMap累加），尤其适合结果集不大（
缓存怎么配才不踩坑？
缓存是加速器，也是双刃剑。重点控制三个边界：
缓存什么？
缓存“结果”，而不是原始行数据。例如缓存
这类聚合键值，而非数百万订单记录。
缓存多久？
根据数据更新频率设定TTL：小时级报表设2小时；日级汇总设24小时；用户标签若T+1更新，缓存可设12小时并配合主动失效（如ETL完成后发MQ清缓存）。
缓存穿透/雪崩防护
：对空结果也缓存短时间（如60秒）；热点key加随机过期时间（如基础TTL±30秒）；核心报表缓存预热（凌晨低峰期主动加载）。
一个典型落地示例
原SQL：查近7天各渠道新客转化率（需关联用户表、行为表、订单表，耗时8.2s）
拆分后流程：
① 缓存读取7天内各渠道总点击UV（来自实时数仓Kafka消费，TTL=1h）；
② 拆成7个独立查询，每天查当日各渠道注册用户数（WHERE date = '2024-06-01' AND event='register'）；
③ 应用层用两组数据做除法，生成转化率列表；
④ 结果整体缓存15分钟，命中率>92%，平均响应降至320ms。
不复杂但容易忽略：拆分后要补监控——跟踪各子查询耗时、缓存命中率、组装阶段CPU占用，避免把数据库压力转移到应用服务器上。
ROW_NUMBER() OVER (PARTITION BY ...){"city":"北京","category":"手机","hour":"14","order_cnt":247}