热数据是近期高频访问的数据，如最近订单，需高性能存储；冷数据是低频历史数据，如一年前记录，可存于低成本介质。MySQL冷热分离通过分区、归档表、归档引擎、跨实例迁移及应用层路由实现，结合自动化工具如pt-archiver定时迁移，降低主库压力与存储成本，同时需注意查询复杂度、锁表风险及冷数据访问性能。
MySQL 实现冷热数据分离（也叫分层存储）的核心思路是：根据数据的访问频率，把“热数据”放在高性能存储中，“冷数据”迁移到低成本、低频访问的存储里，从而在保证性能的同时降低整体成本。这在用户行为日志、订单历史、IoT 数据等场景中非常常见。
什么是热数据和冷数据？
热数据：近期频繁访问的数据，比如最近7天的订单、实时交易记录。这类数据要求响应快，通常保留在主库或高性能SSD上。
冷数据：访问频率极低的历史数据，如一年前的订单、归档日志。可以迁移到机械硬盘、归档表甚至其他数据库中。
常见的冷热数据分离方案
以下是几种在 MySQL 中实现分层存储的实用方法：
-
按时间分区（Partitioning）
使用 MySQL 的表分区功能，按时间字段（如 order_time）将数据划分到不同分区。热数据保留最新分区，冷数据保留在旧分区。查询时优化器会自动裁剪分区，提升效率。
例如：CREATE TABLE orders (id INT, order_time DATETIME) PARTITION BY RANGE (YEAR(order_time)) (...) -
垂直拆分 + 归档表
创建两个结构相同的表：orders_hot和orders_cold。定期通过定时任务（如每天凌晨）将超过设定时间的数据从 hot 表迁移到 cold 表。
应用层查询时先查 hot 表，必要时再查 cold 表，或通过视图统一查询入口。 -
使用归档引擎（如 ARCHIVE 或 TokuDB）
MySQL 支持多种存储引擎。ARCHIVE 引擎适合只读、高压缩比的冷数据存储。TokuDB（适用于 Percona Server）支持高压缩和分形树索引，适合海量数据归档。
可将冷数据 ALTER 到 ARCHIVE 引擎表中，节省空间。 -
跨实例迁移（主+归档库）
热数据保留在主 MySQL 实例，冷数据迁移到专用的归档实例。归档库可用更低配置硬件，甚至启用压缩。可通过 ETL 工具（如 mysqldump、pt-archiver）定期同步。 -
应用层路由控制
在业务代码或中间件（如 MyCat、ShardingSphere）中判断查询的时间范围，自动路由到对应的热表或冷表，对上层透明。
自动化归档建议
手动维护冷热分离容易出错，建议结合脚本自动化处理：
- 使用
pt-archiver（Percona Toolkit 工具）安全地归档并删除旧数据。 - 编写定时任务（cron + Python/Shell 脚本），按时间条件迁移数据。
- 迁移前确保有备份，迁移后验证数据一致性。
注意事项
冷热分离虽然能降本增效，但也带来复杂度：
- 跨表或跨库查询变复杂，可能需要 UNION 或中间件支持。
- 归档过程要避免锁表影响线上业务，建议在低峰期执行。
- 冷数据查询慢，需明确业务容忍度，必要时加索引或做宽表预处理。
基本上就这些。关键是根据业务特点选择合适方案，平衡性能、成本和维护难度。
