归档表命名须含时间标识，如order_2024_q3；建表须显式复制结构并重置AUTO_INCREMENT为1、补全COMMENT；保留主键及关键索引，禁用外键；PHP归档后需校验行数与抽样数据一致性。
归档表命名必须带时间标识，不能只用 _archive 后缀
直接加 _archive 会导致后续无法区分归档批次，查历史数据时得翻日志或代码猜时间范围。实际运维中，归档表名要能一眼看出生命周期，比如 order_2024_q3、log_202409 或 user_action_20241001。
建议统一用以下任一格式（选一种并长期坚持）：
-
原表名_年份季度（如payment_2024_q2），适合按季度归档的业务 -
原表名_年月（如access_log_202409），适合日志类高频写入表 -
原表名_起始日期_结束日期（如order_20240701_20240930），适合需要精确回溯区间的数据
别用 archive_原表名 这种前缀式命名——MySQL 的 SHOW TABLES 默认按字母序排，归档表会散在列表开头，和原表完全分离，不利于肉眼定位关联关系。
建表语句必须显式复制原表结构，禁用 CREATE TABLE ... LIKE
CREATE TABLE new_table LIKE old_table 看似省事，但会漏掉关键细节：自增起始值、索引顺序、外键约束（即使没报错，InnoDB 也不会自动重建外键）、以及 COMMENT 字段说明。更隐蔽的问题是，如果原表用了 ROW_FORMAT=COMPRESSED 或 KEY_BLOCK_SIZE，LIKE 语句在某些 MySQL 版本下根本不继承这些设置。
立即学习“PHP免费学习笔记（深入）”；
正确做法是导出原表 CREATE TABLE 语句，再手动替换表名和注释：
CREATE TABLE `order_2024_q3` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL, `amount` decimal(10,2) NOT NULL, `created_at` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_user_created` (`user_id`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='订单归档表：2024年第三季度';
特别注意：AUTO_INCREMENT 值必须重置为 1（除非你明确需要延续原表 ID 序列，但归档表通常不需要）；COMMENT 里写清归档周期，比字段名还重要——半年后没人记得 order_202409 到底覆盖哪几天。
归档表默认不加外键，但必须保留关键索引
归档表本质是只读历史快照，加外键不仅没意义，还会拖慢 INSERT ... SELECT 归档过程（尤其是源表有大量更新时）。MySQL 在执行外键检查时会锁相关父表记录，而归档操作本身常在业务低峰期跑批，锁等待反而可能引发超时。
但索引不能省——哪怕只是 WHERE created_at BETWEEN ? AND ? 这种简单查询，没索引也会全表扫。重点保留：
- 主键（必须）
- 按时间范围查询的联合索引，如
(created_at, status)或(user_id, created_at) - 业务上高频
GROUP BY或JOIN的字段组合（即使只读，报表也常这么用）
别为了“省空间”删索引。归档表写一次读多次，磁盘成本远低于慢查询带来的 CPU 和连接池压力。
PHP 脚本归档前务必校验数据一致性，不能只信 SELECT COUNT(*)
常见错误是归档脚本执行完就认为 OK，结果发现漏了部分状态为 'pending' 的订单（因为 WHERE status = 'done' 写错了），或者时间条件边界出错（BETWEEN '2024-07-01' AND '2024-09-30' 漏掉 9 月 30 日 23:59:59 的记录）。
建议在 PHP 中做三步验证：
- 归档前：查源表满足条件的记录数，记为
$expected - 归档后：查新表总行数，记为
$actual - 再抽样比对：取 5–10 条源表随机记录的主键，在归档表中
SELECT * WHERE id IN (...)，确认字段值完全一致
最后一项最容易被跳过，但恰恰能发现字符集转换异常（比如源表是 utf8mb4，归档表建成了 utf8，中文变问号）、或 DECIMAL 精度截断等问题。这些错误 COUNT(*) 完全看不出来。
