MySQL存储过程本身不会自动执行，必须显式调用或绑定事件调度器（EVENT）或外部调度器；EVENT常因event_scheduler未开启、STARTS时间设为过去、DEFINER失效、跨库未写全名、大表未分批、缺错误处理及索引等导致静默失效，生产环境需shell脚本兜底。
MySQL 存储过程本身不会自动执行，必须显式调用或绑定到事件调度器（EVENT）或外部调度器（如 crontab）才能定期归档；只写 CREATE PROCEDURE 不调用，它就永远是静态代码。
为什么 EVENT 是最常被误用的“自动归档”方案
很多人以为创建完存储过程再配个 CREATE EVENT 就万事大吉，结果上线后归档静默失效。常见断点包括：
-
event_scheduler默认关闭，必须由 DBA 执行SET GLOBAL event_scheduler = ON，且需要SUPER权限——普通应用账号无权操作 - 查状态不能靠猜：
SHOW VARIABLES LIKE 'event_scheduler'返回ON才算真正启用 -
STARTS '2026-10-14 02:00:00'必须是未来时间，设成过去时间会导致事件状态变为SLAVESIDE_DISABLED，且不会自愈 - 事件默认以
DEFINER账户身份运行，该账户若被删、密码过期或权限回收，事件立即失效，无日志提示 - 跨库调用必须写全库名，例如
CALL archive_db.archive_orders('2026-09-01')，否则在myapp库里定义的事件调不到history_db的表
存储过程内部必须分批处理，不能一次 INSERT + 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无效，实际仍是全表扫描 - 每次循环后用
GET DIAGNOSTICS @rowcount = ROW_COUNT()获取真实影响行数，别信@@ERROR或预估的COUNT(*)
生产环境别只信 EVENT，shell 脚本兜底更可靠
MySQL 事件在实例重启后可能未激活，也无法跨网络连冷备库执行 INSERT。纯靠 EVENT 的方案在生产中风险过高。
- 存储过程只负责从源库读、写入本地临时表或生成 SQL 文件，不直连目标库
- 用
crontab调用 shell 脚本，内含mysqladmin ping -h prod-host和mysqladmin ping -h cold-host双活检测 - 脚本中用
mysql -h cold-host -u user -p'pwd' cold_db -e "LOAD DATA INFILE ..."导入，比事件内远程INSERT更稳定 - 所有输出重定向到日志文件，例如
/var/log/archive/order_daily.log，方便grep错误码和确认执行时间
最容易被忽略的是归档后数据的可查性：冷备库的字符集、时区、TIMESTAMP/DATETIME 行为是否与源库一致？归档表有没有建索引？create_time 字段是否被业务代码动态更新？这些细节漏掉一个，半年后查不到订单就是真问题。
