ThinkPHP历史数据怎么归档_ThinkPHP大表维护指南【汇总】

ThinkPHP 无开箱即用历史数据归档功能，需手动编写迁移逻辑或定时 SQL；归档表须字段/类型/长度/NULL 约束与原表一致，保留主键、去除外键、为查询字段建索引，推荐 ARCHIVE 引擎。

先说个现实：ThinkPHP 并没有自带一个“一键归档”按钮。所有归档动作，都得你亲手写逻辑——要么手动迁移数据，要么用定时任务驱动 SQL 操作。别指望 think-orm 或 Db 类里藏着个 archive() 方法，不存在。

归档表结构必须和原表一致，但要去掉外键

归档不是备份，是把冷数据挪走腾空间。建归档表时，有几个硬性要求必须遵守：

• 字段名、类型、长度、是否允许 NULL 必须和原表完全一致，差一点都不行。
• 主键保留——后续查或删都靠它，少了会出大问题。
• 外键约束一律去掉。归档表不参与业务关联，加了反而拖慢插入。
• 关键查询字段（比如 created_at、state）一定要加索引，否则 SELECT 和 DELETE 都慢得像卡住一样。
• 不要用 ENGINE=InnoDB 存大量归档数据。改用 ARCHIVE 引擎，压缩率高、写入快，但注意它不支持 UPDATE / DELETE，只适合“写一次、读很少”的场景。

用 Db::raw() + 分批 INSERT INTO ... SELECT 最稳

直接 Db::name('article')->where('created_at', '<', '2025-01-01')->select() 再循环插入，很容易内存溢出或超时。正确做法是交给 MySQL 原生执行：

Db::execute("INSERT INTO article_archive SELECT * FROM article WHERE created_at < '2025-01-01' LIMIT 1000");

然后分批删原表数据：

Db::execute("DELETE FROM article WHERE created_at < '2025-01-01' LIMIT 1000");

• 每次只处理 1000 行，避免锁表太久。
• 删完立刻执行 OPTIMIZE TABLE article（仅 MyISAM 必须；InnoDB 大删后建议做）。
• 删之前先 ANALYZE TABLE article，让优化器更新统计信息，避免后续查询走错索引。

定时归档不能只靠 PHP 脚本跑一遍

用 Linux Cron 调 php /path/to/archive.php 是常见做法，但容易踩三个坑：

• 脚本没加互斥锁，多个 cron 同时跑导致重复归档或删库。
• 没检查上一次执行是否卡死或失败，下次直接覆盖跑。
• 没记录归档进度（比如最后处理的 id 或时间戳），断点续传做不到。

推荐在数据库里建一张 archive_log 表，每次归档前写入开始时间、表名、条件时间点；成功后更新结束时间和状态。下次执行先查最近一条未完成记录，接着往下跑。

ThinkORM 模型里别硬塞归档逻辑

有人喜欢在 ArticleModel 里加个 archiveOldData() 方法，然后在控制器里调用。这看着干净，实际很危险：

• 归档操作通常要跨连接（主库 + 归档库），模型默认只连一个库。
• 大事务下模型的自动事件（before_write 等）可能干扰归档流程。
• 一旦归档中途出错，模型层难 rollback，容易出现“部分迁移、部分残留”。

归档逻辑应该独立成命令行脚本（如 app/command/ArchiveCommand.php），用 Db::connect('archive') 显式指定目标库，全程绕过模型生命周期。

归档最麻烦的从来不是代码怎么写，而是删之前敢不敢确认那批数据真的没人查、没人导、没人依赖——线上环境，永远先查再删，删完再验，验完再睡。