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', 'select() 再循环插入，容易内存溢出或超时。正确做法是交给 MySQL 原生执行：
Db::execute("INSERT INTO article_archive SELECT * FROM article WHERE created_at <p>然后分批删原表数据：</p><pre class="brush:php;toolbar:false;">Db::execute("DELETE FROM article WHERE created_at <p>– 每次只处理 1000 行，避免锁表太久<br>– 删完立刻执行 <code>OPTIMIZE TABLE article</code>（仅 MyISAM 必须；InnoDB 大删后建议做）<br>– 删之前先 <code>ANALYZE TABLE article</code>，让优化器更新统计信息，避免后续查询走错索引</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill5233" title="btpanel phpsite 宝塔面板PHP网站"><img
src="https://img.php.cn/upload/skill/000/000/081/179040786932301.jpg" alt="btpanel phpsite 宝塔面板PHP网站" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill5233" title="btpanel phpsite 宝塔面板PHP网站" class="overflowclass">btpanel phpsite 宝塔面板PHP网站</a>
<p class="overflowclass">宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理</p>
</div>
<a rel="nofollow" href="/xiazai/skill5233" title="btpanel phpsite 宝塔面板PHP网站" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><h3>定时归档不能只靠 PHP 脚本跑一遍</h3><p>用 Linux Cron 调 <code>php /path/to/archive.php</code> 是常见做法，但容易踩三个坑：</p>
- 脚本没加互斥锁，多个 cron 同时跑导致重复归档或删库
- 没检查上一次执行是否卡死或失败，下次直接覆盖跑
- 没记录归档进度（比如最后处理的
id或时间戳），断点续传做不到
推荐在数据库里建一张 archive_log 表，每次归档前写入开始时间、表名、条件时间点；成功后更新结束时间和状态。下次执行先查最近一条未完成记录，接着往下跑。
ThinkORM 模型里别硬塞归档逻辑
有人喜欢在 ArticleModel 里加个 archiveOldData() 方法，然后在控制器里调用。这看着干净，实际很危险：
- 归档操作通常要跨连接（主库 + 归档库），模型默认只连一个库
- 大事务下模型的自动事件（
before_write等）可能干扰归档流程 - 一旦归档中途出错，模型层难 rollback，容易出现「部分迁移、部分残留」
归档逻辑应该独立成命令行脚本（如 app/command/ArchiveCommand.php），用 Db::connect('archive') 显式指定目标库，全程绕过模型生命周期。
归档最麻烦的从来不是代码怎么写，而是删之前敢不敢确认那批数据真的没人查、没人导、没人依赖——线上环境，永远先查再删，删完再验，验完再睡。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
