MySQL RANGE分区实现冷热分离需用TO_DAYS按时间分区并指定不同表空间，PHP仅负责执行SQL或通过分表路由模拟；冷数据须只读冻结、校验迁移，DAO层需双查兜底与SQL审计。
用 MySQL RANGE 分区直接建冷热分离表
PHP 本身不负责建表，但你得在 PHP 部署脚本或迁移工具（如 Laravel Migrate、Phinx）里执行正确的 SQL。最轻量、最可控的方式是让 MySQL 原生支持冷热物理分离——用 RANGE 分区按时间切分，把热数据（如近 6 个月）放在高速 SSD 表空间，冷数据（如 2022 年订单）落到 HDD 或归档表空间。
关键不是“PHP 怎么写”，而是你发给 MySQL 的那条 CREATE TABLE ... PARTITION BY RANGE 是否合理：
- 必须有明确的分区键，通常是
created_at或order_date，且该字段要建索引 - 每个分区需显式指定
TABLESPACE，否则默认共用主表空间，起不到资源隔离作用 - MySQL 8.0+ 才支持为不同分区指定不同表空间；5.7 只能靠分表模拟（见下一条）
- 分区不能动态收缩，新增分区需定期维护（可用 PHP + Cron 自动补）
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id INT NOT NULL,
amount DECIMAL(10,2),
created_at DATETIME NOT NULL
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p_hot VALUES LESS THAN (TO_DAYS('2025-07-01')) TABLESPACE ssd_fast,
PARTITION p_cold_2024 VALUES LESS THAN (TO_DAYS('2025-01-01')) TABLESPACE hdd_archive,
PARTITION p_cold_2023 VALUES LESS THAN (TO_DAYS('2024-01-01')) TABLESPACE hdd_archive,
PARTITION p_older VALUES LESS THAN MAXVALUE TABLESPACE hdd_archive
);PHP 中用 PDO 模拟分区：手动分表 + 路由逻辑
如果你用的是 MySQL 5.7 或云数据库（如阿里云 RDS）不支持跨分区指定表空间，那就退一步：用 PHP 控制「逻辑分区」——按月/按年生成独立表名，再由代码决定查哪张表。这不是真分区，但成本低、兼容性强，适合中小团队快速落地。
核心是别让业务层感知分表，所有路由逻辑收在 DAO 层：
立即学习“PHP免费学习笔记（深入）”；
- 表名格式统一，例如
orders_202508、orders_202412，用date('Ym', $ts)生成 - 查询时根据
WHERE created_at BETWEEN ? AND ?自动推导目标表，避免全表扫描 - 写入时先判断时间归属，再
INSERT INTO orders_202508，不要硬写死表名 - 注意事务边界：跨月写入（如批量导入历史数据）无法单事务完成，得降级为应用层补偿
示例路由片段：
$month = date('Ym', strtotime($order['created_at']));
$table = "orders_{$month}";
$sql = "INSERT INTO {$table} (user_id, amount, created_at) VALUES (?, ?, ?)";
$stmt = $pdo->prepare($sql);
$stmt->execute([$order['user_id'], $order['amount'], $order['created_at']]);冷表迁移成本高？优先冻结而非删除
很多人以为“冷数据迁走就完事了”，结果发现迁移过程锁表、慢查询暴增、备份失败——根本原因是没区分“冷”和“死”。真正可迁的冷数据必须满足：无写入、极少读取、结构稳定。否则迁移反而是负优化。
实操建议：
- 先加只读约束：
ALTER TABLE orders_202306 READ ONLY;（MySQL 5.7+），防止误更新 - 冷表不急着导出，先用
mysqldump --no-create-info --skip-triggers快速导出数据，比SELECT INTO OUTFILE更稳 - 导出后，用 PHP 脚本校验行数 + 随机抽样 MD5，别信“导完了就对了”
- 迁移目标如果是对象存储（OSS/S3），别存裸 SQL，转成 Parquet 或压缩 CSV，后续分析成本直降 60%+
别忽略 PHP 层的双查兜底逻辑
哪怕你建了分区、分了表，业务代码仍可能写出 SELECT * FROM orders WHERE user_id = ? 这种无时间条件的语句——它会扫全分区/全分表。此时光靠 DB 层优化没用，必须在 PHP DAO 层加一层“冷热双查”保护。
简单但有效的做法：
- 默认只查热表（如
orders_recent或orders_2025*），超时或无结果时，再触发冷表查询（带日志告警） - 用
EXPLAIN结果判断是否命中分区：若partitions字段显示NULL或全表，则立刻拦截并报错 - 在 CI 流程中加入 SQL 审计规则，禁止
WHERE不含分区键的SELECT进生产
冷热分离不是建完表就结束的事，真正的成本藏在后续每一次查询的意图识别和 fallback 控制里。越早把“查哪张表”从 SQL 里剥离到 PHP 配置或注解里，后期运维越省心。
