MySQL冷热分离不是内置功能，需靠外部策略实现：先定义冷热边界，再定时导出冷数据至ClickHouse或HDFS，最后删除原表数据；分区表仅支持本地逻辑切分，无法跨系统迁移。
冷热分离不是MySQL内置功能，得靠外部策略落地
MySQL本身不识别“冷”“热”概念，也没有自动迁移、自动分层的机制。所有所谓“冷热分离”，本质是人为定义边界 + 手动或定时执行数据移动 + 应用层配合路由。别指望ALTER TABLE ... SET HOT=FALSE这种语法存在——它根本不存在。
常见错误现象包括：在配置里加storage_engine='cold'导致启动失败；试图用DATA DIRECTORY指向HDFS路径，结果报错Unknown storage engine 'hdfs'；或者以为分区表能自动把老分区“推”到ClickHouse，实际只是本地文件挪了个目录。
- 分区表只做逻辑切分，物理仍存于MySQL本地磁盘，无法跨系统
-
EXCHANGE PARTITION只能交换InnoDB表，且目标表必须结构完全一致、无外键、无数据 -
secure_file_priv限制SELECT INTO OUTFILE写入路径，硬改配置重启生产库风险极高
RANGE分区是冷热分离最可行的原生手段
按时间字段（如create_time）做PARTITION BY RANGE，是MySQL内唯一能接近“自动分流”的方式。但前提是分区键必须包含在主键或唯一索引中，否则建表直接报错ERROR 1503 (HY000)。
使用场景明确：订单、日志、监控等强时间序列数据。别用LIST分区——它只认枚举值，没法表达“2024年之前”这种连续区间。
- 查询必须带分区键条件（如
WHERE create_time >= '2026-01-01'），否则优化器不裁剪，照样扫全表 -
DROP PARTITION后磁盘空间不释放，需后续执行OPTIMIZE TABLE或ALTER TABLE ... ENGINE=InnoDB重建 - 新增分区不能靠
ALTER TABLE ADD PARTITION无限追加，建议提前建好未来3–6个月的分区，避免DDL阻塞
归档到ClickHouse/HDFS必须走导出+导入两步
想把冷数据从MySQL搬到ClickHouse或HDFS，没有捷径。必须先从MySQL导出（mysqldump --where或SELECT INTO OUTFILE），再用对应工具导入目标系统。中间任何一步断开，数据就丢了。
性能与兼容性影响明显：ClickHouse不支持UPDATE/DELETE，必须用ReplacingMergeTree引擎+version字段模拟幂等；HDFS上存CSV或Parquet，得自己处理字段类型映射和NULL值。
- 导出时别用
YEAR(create_time)这类函数条件——会失效索引，导致全表扫描 - 用
EXPLAIN PARTITIONS验证是否真只扫目标分区，防止误导热区数据 - 删除MySQL侧冷数据前，务必确认导出成功且目标端校验通过，否则不可逆
应用层路由比数据库层更可控，但也更重
当冷热数据已物理分离（比如orders_hot和orders_his两个表），查询就得由应用决定走哪条路。视图UNION ALL兜底简单查询可行，但排序、分页、JOIN复杂查询会拖慢冷表响应，且无法下推谓词。
容易被忽略的是冷数据访问提示和索引精简：用户查三年前订单，前端应显示“历史数据查询可能延迟2–5秒”；冷表只保留PRIMARY KEY和高频单查字段（如user_id）的索引，禁用联合索引、全文索引。
- DAO层拦截条件自动路由，看似灵活，但事务一致性难保障，跨源
INSERT ... SELECT极易出错 - MySQL Router或ShardingSphere可聚合结果，但引入中间件意味着多一层故障点和运维成本
- 冷表备份策略要独立：冷库可关
binlog、调低innodb_buffer_pool_size，甚至用低配机型部署
