SQL存储过程如何实现历史表数据归档：定期迁移旧数据到冷备库
归档前必须确认的三个检查点
直接动手删除老数据？这无异于给线上数据库埋下一颗定时冲击波。归档的本质是“先搬后删”，但前提是搬得稳、删得准、未来还得查得到。动手前，务必确认以下三点：
- 时间字段有索引：
WHERE条件里的时间字段必须有索引。否则，执行DELETE时可能会触发全表扫描和锁表，阻塞时间动辄几十秒，业务高峰期就是一场灾难。 - 表结构一致性：目标冷备库的表结构必须与源表完全一致。这不仅仅是字段名和类型，更要留意默认值、约束、字符集。尤其要注意
TIMESTAMP和DATETIME字段的时区行为差异，一个疏忽就可能导致数据“穿越”。 - 窗口与事务控制：归档操作必须严格避开业务高峰窗口。同时，整个事务的大小不能超过 MySQL 的
max_allowed_packet限制，执行时间也要控制在innodb_lock_wait_timeout之内，避免长事务拖垮系统。
用 INSERT … SELECT + DELETE 分两步最可控
别试图用一个存储过程封装“自动插+自动删”的大事务。想法很美好，但一旦中间环节失败，状态回滚会变得异常复杂。拆分成两个原子操作，可控性会强得多：
- 第一步：迁移数据：使用
INSERT INTO cold_db.order_archive SELECT * FROM prod_db.orders WHERE create_time < '2023-01-01'。强烈建议加上LIMIT 10000子句进行分批插入，这是避免长事务阻塞的黄金法则。 - 第二步：确认后删除：在确认第一步插入的行数完全匹配后，再执行
DELETE FROM prod_db.orders WHERE create_time < '2023-01-01'。两步操作之间，就是一道安全防线。 - 关键检查：两步操作后都立即执行
SELECT ROW_COUNT()，核对实际影响的行数。这个简单的习惯，能有效防止因条件写错而导致的误删悲剧。
存储过程里必须带事务控制和错误捕获
这里有个关键认知：MySQL 存储过程默认不会自动回滚事务。这意味着，一旦过程中某条语句出错，过程可能会停在半途，留下一个“半成品”状态。因此，核心逻辑必须被妥善包裹：
- 显式事务：在存储过程开头使用
START TRANSACTION，并在结尾明确执行COMMIT或ROLLBACK。 - 错误处理：使用
DECLARE EXIT HANDLER FOR SQLEXCEPTION来声明异常处理程序，确保任何错误都能触发回滚。 - 行数跟踪：每次
INSERT操作后，立即使用GET DIAGNOSTICS @rowcount = ROW_COUNT来捕获成功插入的行数。如果发现@rowcount = 0，说明没有符合条件的数据，应该直接退出流程，避免无意义的空跑。 - 避免过时方法：不要依赖
@@ERROR这类旧式变量来判断错误，它只记录上一条语句的状态，在多语句过程中并不可靠。
定时调度别只靠 EVENT，加一层 Shell 脚本兜底
依赖 MySQL 的 EVENT 来做定时归档？这可能会带来两个问题：一是实例重启后事件可能失效；二是它通常无法直接跨库连接冷备库执行 INSERT。更稳健的方案是组合出击：
- 各司其职：让存储过程专注于核心数据操作，比如从源库读取数据，并写入本地临时表或生成标准的 SQL 文件。
- 脚本调度：使用 Linux 的
crontab来定时调用一个 Shell 脚本。这个脚本通过命令行连接冷备库，执行类似mysql -h cold-host -u user -p'pwd' cold_db -e "LOAD DATA INFILE ..."的命令来完成最终导入。 - 健康检查：在脚本中，加入对生产库和冷备库的双活检测，例如使用
mysqladmin ping，确保两端服务都正常再执行操作。 - 日志追踪：将所有操作日志，包括成功信息和错误码，统一输出到指定文件，例如
/var/log/archive/order_daily.log。日后排查问题时，一个grep命令就能定位关键信息。
最后必须强调，数据归档绝非一劳永逸的“一次性动作”。它关联着一系列需要持续关注的细节：create_time 字段是否会被业务代码意外更新？如果使用了分区表，归档后的 EXCHANGE PARTITION 操作是否同步执行？冷备库的备份策略是否已经覆盖了新归档的表？这些环节漏掉任何一个，都可能在未来某个时刻，让“查不到历史订单”从一个技术风险变成真实的业务问题。
