冷热数据拆分需精准识别访问陡降点确定动态边界，保持表结构一致，通过视图/中间件实现查询自动路由，并以事务化归档、压缩存储及基础运维保障稳定性。
冷热数据拆分的核心是把高频访问的“热数据”和低频访问的“冷数据”物理隔离，提升查询性能、降低存储成本、简化维护。关键不在“要不要分”，而在于“怎么分得准、切得稳、查得顺”。
明确冷热边界：别靠拍脑袋，用数据说话
热数据不是“最近一个月”，冷数据也不是“三年前”。必须结合业务访问日志或SQL审计数据统计：
- 统计各时间分区（如按天/月）的查询频次、平均响应时间、扫描行数
- 识别访问陡降点——例如订单表中，90%的查询集中在近90天，而90–180天区间查询量下降70%，这个拐点就是天然分界线
- 避免静态规则（如“所有2022年前数据归冷”），要定期重算边界，尤其在业务增长或活动周期变化后
表结构设计：保持逻辑一致，减少应用改造
冷表和热表字段定义必须完全一致（含类型、长度、约束），否则联合查询或迁移会出错。推荐做法：
- 热表命名如 order_info_hot，冷表如 order_info_cold，不加年份/月份后缀，避免无限建表
- 共用同一套DDL脚本，通过变量或部署参数控制生成目标表名，确保结构同步
- 主键、索引策略按访问特征差异化：热表建覆盖索引加速常用查询；冷表可精简索引，甚至只保留主键+分区键
查询路由：让SQL自动走对表，不依赖人工判断
应用层不应硬编码查 hot 还是 cold。可行方案有：
- 视图 + 条件路由：建统一视图 v_order_info，内部用 UNION ALL + WHERE 时间条件分流，数据库优化器能裁剪无效分支（需确保条件可下推）
- 中间件路由：ShardingSphere、MyCat 等支持基于时间字段的分片策略，SQL 不改，自动路由到对应物理表
- 存储过程封装：对复杂查询封装为 SP，入参含时间范围，内部判断并执行对应表查询，对外接口不变
数据归档与同步：冷热切换要原子、可逆、可观测
归档不是“删完再插”，而是带校验、留痕迹、能回滚：
- 归档任务使用事务或两阶段提交：先 insert into cold select…，再 delete from hot where…，失败则全回滚
- 每次归档记录元数据：归档时间、源表范围、行数、MD5摘要（抽样）、耗时，写入 archive_log 表供追踪
- 冷表启用压缩（如 InnoDB PAGE_COMPRESSION、列存引擎），但归档前务必验证解压查询性能，避免“省了空间，拖慢报表”
不复杂但容易忽略：冷表也要做基础运维——定期 analyze table 更新统计信息，监控 slow log 中冷表误查情况，设置冷表只读权限防误更新。
