不能直接用 create table ... like 复制订单表结构，因其会原样复制 auto_increment、foreign key 和触发器，导致归档插入失败或锁表；应手动修改 show create table 语句，移除自增与外键，改用联合索引和时间分区。
为什么不能直接用 CREATE TABLE ... LIKE 复制订单表结构？
因为历史订单表需要保留原始字段、索引和约束，但通常要移除主键自增、外键（避免归档时触发级联）、以及某些业务触发器。直接 LIKE 会原样复制所有 DDL 属性，包括 AUTO_INCREMENT 和 FOREIGN KEY，后续插入归档数据可能失败或引发锁表。
实操建议：
- 用
SHOW CREATE TABLE orders导出建表语句，手动删掉AUTO_INCREMENT、PRIMARY KEY（归档表一般改用联合索引 + 时间分区键），以及所有FOREIGN KEY定义 - 把
id字段改为普通BIGINT，不设主键；用(order_no, created_at)建唯一索引，兼顾查询与去重 - 归档表名统一用
orders_202401格式，便于后期按月批量操作
如何安全地把 2023 年 12 月订单迁入 orders_202312？
不能用 INSERT INTO ... SELECT 一次性搬，尤其当源表有百万级数据时：会锁表、阻塞线上写入、事务日志暴涨。必须分批 + 低峰期执行 + 检查点保障。
实操建议：
- 用
SELECT id FROM orders WHERE created_at >= '2023-12-01' AND created_at 分页取主键，避免 <code>OFFSET性能退化 - 每批处理完立即
DELETE FROM orders WHERE id IN (..)，并确认affected_rows === 1000，防止漏删或误删 - 在事务外执行迁移（即不包
BEGIN/COMMIT），避免长事务拖垮 binlog；但每批内部用事务保证原子性 - 迁移前先对目标表
orders_202312执行ANALYZE TABLE，更新统计信息，避免优化器选错执行计划
mysqli 或 PDO 执行归档 SQL 时，为什么总遇到 MySQL server has gone away？
归档过程常涉及大结果集遍历、长连接空闲超时、或单次 SQL 过长（比如拼了上千个 id 的 IN 子句）。错误本质是连接被服务端主动断开。
实操建议：
- 用
PDO::ATTR_TIMEOUT和mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 30)显式设连接超时，但更关键是控制单次操作粒度 - 禁用
mysqli的MYSQLI_STORE_RESULT模式（默认），改用MYSQLI_USE_RESULT流式读取，减少内存占用 - 对批量
DELETE，永远用WHERE id BETWEEN ? AND ?替代IN列表，避免 SQL 长度超限（max_allowed_packet） - 每次循环后调用
$pdo->getAttribute(PDO::ATTR_CONNECTION_STATUS)检查连接状态，异常则重连
归档脚本跑在 crontab 里，怎么避免多实例并发冲突？
crontab 每天凌晨执行一次，但如果某次归档耗时超过 24 小时（如网络抖动、磁盘慢），下次任务启动时就会和上一个进程争抢同一批数据，导致重复归档或漏数据。
实操建议：
- 脚本开头立刻尝试获取 MySQL 表级锁：
SELECT GET_LOCK('archive_orders_lock', 0)，返回 0 直接退出 - 归档完成后必须显式释放：
SELECT RELEASE_LOCK('archive_orders_lock')，不能依赖进程退出自动释放 - 加文件锁作为第二道防线：
flock -n /tmp/archive_orders.lock -c 'php archive.php'，避免 MySQL 锁失效时的兜底风险 - 记录最后成功归档的
created_at时间戳到独立配置表（如archive_progress），每次启动先查再算范围，不依赖固定时间窗口
2023-12-31 23:59:59.999）、时区配置不一致（PHP date_default_timezone_set() 和 MySQL time_zone 不匹配）、以及归档后未及时更新统计信息导致查询变慢。这些地方不打日志、不校验，线上就只能靠 EXPLAIN 硬查。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
