冷热数据拆表需基于访问模式与业务语义识别冷热边界，优先逻辑隔离+索引优化，必要时物理拆分并保障主键一致、异步归档与查询路由。
冷热数据拆表不是简单按时间切分，关键在识别访问模式、权衡查询效率与维护成本。核心思路是让热数据轻量、高频、易缓存，冷数据归档、压缩、低频访问。
明确冷热边界：别只看时间，要看访问频率和业务语义
热数据不等于“最近30天”，而是实际被高频读写的数据。比如订单表中，已支付且未完成的订单是热的；已完成超90天或已关闭的订单才是冷的。用户行为日志里，近7天埋点用于实时分析是热的，更早的仅用于月度统计就是冷的。
- 用监控工具（如慢查日志、SQL审计）统计各时间段数据的查询QPS和扫描行数
- 结合业务规则定义冷热——例如“状态=已完结且更新时间>180天”比“创建时间
- 避免一刀切：同一张表内不同字段冷热可能不一致（如订单主表热，但其扩展属性表可整体归档）
拆表策略选型：按需选择继承、分表或分离存储
不是所有场景都适合物理拆成两张表。优先考虑逻辑隔离+索引优化；确有性能瓶颈再物理拆分。
- 单表+分区+覆盖索引：适用于MySQL 8.0+或PostgreSQL，按时间/状态分区，热区保留常驻内存，冷区自动走慢速路径
- 双表+应用路由：热表（order_hot）只存活跃订单，冷表（order_archive）存归档数据；写入时由服务判断状态写入对应表，查询走统一DAO做合并或分流
- 冷表转对象存储：超1年冷数据导出为Parquet格式存OSS/S3，通过外部表（如Presto、Doris外表）按需查询，主库零负担
表结构同步与一致性保障：冷热之间不能失联
拆开后最怕数据不一致或查询断裂。必须设计好主键、关联逻辑和生命周期协同机制。
- 热表和冷表保持相同主键结构（如order_id），避免JOIN时类型或长度不匹配
- 用触发器或CDC（如Canal/Debezium）监听热表变更，异步归档到冷表，注意幂等和延迟容忍
- 对跨冷热的统计类查询（如“历史总下单量”），用UNION ALL + 条件下推，或预聚合到汇总表，别直接全表扫
查询层适配：让应用无感，但数据库高效
拆表不是甩给DBA的事，应用层要配合做路由、降级和兜底。
- DAO层封装冷热路由逻辑：根据参数（如status、create_time）自动选择查hot表还是archive表
- 对模糊查询（如“搜订单号”）必须同时查两表，但限制返回条数+加超时熔断，防拖垮冷表
- 提供冷数据查询入口但标注“延迟1~5分钟”，后台异步拉取并缓存结果，前端展示loading态
冷热拆分本质是数据生命周期管理的具体落地。不追求一步到位，先从一个高负载、特征明显的表试点，验证QPS下降、慢查减少、备份时间缩短等指标，再逐步推广。结构可以调，逻辑可以补，但数据不动、业务不卡，才是真优化。
