PHP不负责冷热分离的物理实现，仅承担路由、判断、连接切换和归档触发职责；真实分离需依赖MySQL分区、双库结构或S3+元数据表等外部方案。
直接说结论：PHP 本身不负责冷热分离的物理实现，它只承担路由、判断、连接切换和归档触发职责；真正的分离必须由 MySQL 分区、双库结构或外部存储（如 S3 + 元数据表）完成。用 PHP 硬写“if 时间早于 180 天就查 archive_orders”是能跑通，但漏掉事务校验、索引同步、跨库一致性这几条，线上大概率丢数据或查不到。
MySQL 原生分区表 + PHP 路由判断
这是最轻量、也最容易翻车的方案——适合 MySQL 8.0+、有 DBA 配合、且业务表主键含时间字段（如 created_at）的场景。
- 分区语句必须带
TO_DAYS(created_at)或YEAR(created_at)，不能用NOW()这类运行时函数，否则无法做静态分区裁剪 - PHP 中不能直接
SELECT * FROM orders WHERE created_at < '2025-01-01'，而要先解析条件，推导出目标分区（如p_cold_2024），再拼SELECT * FROM orders PARTITION(p_cold_2024)，否则优化器可能全扫 - 新增分区需定时补，比如每月 1 号执行
ALTER TABLE orders REORGANIZE PARTITION p_older INTO (PARTITION p_202505 VALUES LESS THAN (...), PARTITION p_older VALUES LESS THAN MAXVALUE)，这个动作得用 PHP 脚本 + 宝塔计划任务兜底 - 分区键字段（
created_at）必须单独建索引，否则按order_id查询会退化成全分区扫描
PDO 连接切换读取归档库
当主库压力大、或历史查询频次低但又不能离线时，双库分离是最稳的选择。PHP 的角色是「智能路由」，不是「数据搬运工」。
- 不要在每次请求里都
new PDO()切库，而是复用连接池或封装DB::archive()和DB::primary()两个静态实例 - 路由逻辑必须前置：比如用户传
start_time=2024-03-01，PHP 就该立刻判断是否< date('Y-m-d', strtotime('-90 days'))，然后决定用哪个 PDO 实例，而不是先查主库没结果再 fallback 到冷库 - 冷库表结构必须和主库一致，且关键字段（如
order_id、user_id）要有索引——别信“反正不常查就不建索引”，抽检时SELECT * FROM archive_orders WHERE order_id = ?没索引就是 5 秒起步 - 归档脚本必须用
INSERT INTO archive_orders SELECT ... FROM primary_orders WHERE ...+ROW_COUNT()校验行数，确认写入成功后再DELETE，否则中间崩溃等于丢数据
mysqldump 导出 + 文件归档的坑
宝塔面板里点几下就能配的方案，但实际线上故障最多。根本原因是把「备份」当「归档」用。
立即学习“PHP免费学习笔记（深入）”；
-
mysqldump --where="created_at < '2025-01-01'"导出后，DELETE语句必须用完全相同的 WHERE 条件，建议提取成变量统一管理，手写极易错位 - 导出的 SQL 文件不能直接扔进 NAS 就完事，得额外维护一张元数据表（如
cold_data_manifest），记录文件名、时间范围、MD5、导入状态，否则半年后你根本不知道cold_2024Q3.sql里有没有包含 2024-09-30 的数据 - 这种方案无法支持在线查询，用户要查 2023 年订单？只能人工捞文件 +
mysql -u root < cold_2023.sql临时导入，延迟高、不可控，只适合合规存档类需求 - 注意
mysqldump默认不导出视图、存储过程，如果归档表依赖这些对象，得手动补上--routines --triggers
最常被忽略的一点：冷数据不是「冻住就完事」。无论用哪种方案，都得每月跑一次抽检脚本，随机选 10 条冷库记录，反向查原始业务字段是否可读、时间范围是否对齐、关联表外键是否还有效——没有验证的归档，等于埋了个定时丢数据的雷。
