MySQL存储过程本身不会自动执行，必须配合事件调度器或外部调度器才能实现自动化归档；需显式开启event_scheduler、使用未来STARTS时间、分批处理大表、加索引、建错误处理，并在生产环境辅以shell脚本兜底。
MySQL 存储过程本身不会自动执行，必须配合事件调度器（EVENT）或外部调度器（如 cron）才能实现自动化归档。只写一个 CREATE PROCEDURE，不调用它，它就永远是静态代码——这点常被误认为“写了就能跑”，结果上线后归档静默失效。
MySQL 事件调度器必须显式开启且权限到位
事件调度器默认关闭，SET GLOBAL event_scheduler = ON 是硬性前提，且需要 SUPER 权限。普通应用账号通常没这权限，DBA 必须提前授权。
- 创建事件前先查状态：
SHOW VARIABLES LIKE 'event_scheduler';，返回ON才算生效 - 事件定义里必须写全库名，比如
CALL myapp.archive_orders('2026-06-01');，否则跨库调用会失败 -
STARTS时间必须是未来时间，设成过去时间（如写错成'2025-01-01'），事件状态会变成SLAVESIDE_DISABLED，且不会自动恢复 - 事件默认以
DEFINER账户身份运行，如果该账户被删或密码过期，事件直接失效，无日志提示
存储过程内部必须分批处理 + 显式事务控制
一次性 INSERT INTO ... SELECT + DELETE 大表，极易锁表、超时、触发 max_allowed_packet 或 innodb_lock_wait_timeout。归档逻辑不能图省事写成单条大语句。
- 用
REPEAT ... UNTIL ROW_COUNT() = 0循环，每次只操作LIMIT 1000行 - 开头加
START TRANSACTION，结尾根据成功与否显式COMMIT或ROLLBACK - 必须用
DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获错误，否则出错就停在半途，数据状态不一致 - WHERE 条件字段（如
create_time）必须有索引，否则LIMIT无效，实际仍是全表扫描
生产环境别只信 EVENT，加 shell 脚本兜底更可靠
MySQL 事件在实例重启后可能未自动激活，也无法跨网络连冷备库执行 INSERT。纯靠 EVENT 的方案在生产中风险过高。
- 存储过程只负责从源库读、写入本地临时表或生成 SQL 文件，不直连目标库
- 用
crontab调用 shell 脚本，内含mysqladmin ping双活检测（源库 + 冷备库） - 脚本中用
mysql -h cold-host -u user -p'pwd' cold_db -e "LOAD DATA INFILE ..."导入，比事件内远程 INSERT 稳定 - 所有输出重定向到日志文件，例如
/var/log/archive/order_daily.log，方便 grep 错误码和确认执行时间
最容易被忽略的是归档后数据的可查性：冷备库的字符集、时区、TIMESTAMP/DATETIME 行为是否与源库一致？归档表有没有建好对应索引？分区表归档后，EXCHANGE PARTITION 是否同步更新？漏掉其中任意一点，半年后业务方查不到历史订单，问题就不是技术细节，而是线上事故。
