实现冷热数据完全隔离的关键是tmpfs、SSD、HDD/对象存储三层物理隔离：tmpfs仅存临时可丢小对象（生命周期≤单次运行），SSD专存7天内原始日志及高频访问热数据并锁定元数据路径，冷数据必须导出至OSS/S3或HDD且从数据库元数据中彻底解耦。
要实现数据库冷热数据的完全隔离，关键不是堆硬件，而是让tmpfs和ssd各司其职、互不干扰——tmpfs只承载真正临时、可丢、高频小对象；ssd专注承载近期不可丢、需低延迟访问的热数据；冷数据则必须离开本地，落盘到hdd或对象存储。三者之间不能混用路径、不能共享挂载点、不能共用同一套元数据管理逻辑。
明确每层的数据边界与生命周期
冷热完全隔离的前提是定义清晰、可执行的分层规则，避免“模糊热区”导致数据错位：
-
tmpfs层（超热+临时）：仅存放会话缓存、实时聚合中间结果、秒级滚动窗口指标等，生命周期≤容器/服务单次运行周期，断电即清。例如Elasticsearch的translog缓冲区、ClickHouse的
buffer表临时写入区。 - SSD层（核心热数据）：固定保留最近7天原始日志、近30天结构化业务表（如订单、用户行为）、所有带索引且QPS＞10的字段。这部分数据必须常驻SSD，元数据（如ClickHouse的parts元信息、MySQL的ibdata）也必须锁定在SSD路径下。
-
冷数据层（严格离线）：90天前全量归档数据、审计日志备份、已关闭订单快照等。它们不应出现在任何本地磁盘挂载路径中，而应通过ETL任务导出至OSS、S3或独立HDD阵列，并从数据库元数据中彻底解除关联（如MySQL分区
DROP PARTITION后异步归档）。
物理路径与挂载策略必须硬隔离
软件标记或配置开关无法保证“完全隔离”，必须从操作系统层切断跨介质访问可能：
- tmpfs挂载使用独立
size=限制，例如：mount -t tmpfs -o size=2g,mode=1777 tmpfs /var/lib/mysql/tmpfs_cache，且禁止在该路径下创建符号链接指向SSD分区。 - SSD卷单独格式化为XFS，禁用atime、启用dax（若支持），挂载选项含
noatime,nodiratime,logbufs=8；路径如/data/ssd/mysql_hot，且数据库配置中datadir、innodb_log_group_home_dir等全部显式指向此路径。 - HDD或OSS不以本地文件系统方式挂载进数据库进程空间。冷数据导入导出必须走专用Agent（如Logstash冷迁插件、Hologres cold-exporter），全程不经过数据库引擎I/O栈。
中间件层绑定不可绕过、不可降级
数据库自身必须强制执行分层策略，不能依赖应用层判断或定时脚本补救：
- ClickHouse建表时强制指定
SETTINGS storage_policy = 'ssd_only'，并禁用默认default策略；冷数据表统一用ENGINE = S3('https://oss-bucket/...')直接对接对象存储。 - MySQL按时间分区表，热分区（如
p202605）DATA DIRECTORY = '/data/ssd/partitions'，冷分区（如p202501）用ALTER TABLE ... DROP PARTITION后由外部工具归档，不再保留在datadir内。 - Elasticsearch通过ILM策略将
hot阶段强制路由到仅含SSD节点的node.attr.disk_type:ssd节点组，frozen阶段索引必须设置"store.type": "read_only_store"并挂载只读OSS FS。
监控与验证必须覆盖三层一致性
隔离是否生效，不能只看写入路径，要看实际I/O流向和数据存在状态：
- 对tmpfs：监控
df -h /var/lib/mysql/tmpfs_cache使用率 +cat /proc/mounts | grep tmpfs确认无swap回退；检查数据库日志中是否出现write to tmpfs failed: No space left on device——这说明size设小了，不是隔离失败，而是容量规划不足。 - 对SSD：用
iostat -x 1盯住await lsof -p $(pgrep mysqld) | grep ssd返回所有句柄均落在SSD路径下。 - 对冷层：定期抽查冷数据对象MD5（如OSS中
ossutil head oss://bucket/log_202501.gz）与源库导出时校验值一致，并确认数据库information_schema.PARTITIONS或system.parts中已无对应分区记录。
