能实现安全清洗，需调度器启用、存储过程封装、索引优化和执行节制四层配合；event仅负责触发，真正清理由带limit/预检/错误捕获的存储过程完成，云环境推荐crontab调用替代。
能实现，但“安全清洗”不靠EVENT本身，而靠调度器开启、语句设计、索引保障和执行封装四层配合。直接在EVENT里写DELETE很容易锁表、误删或静默失败。
先确认并永久启用event_scheduler
这是所有后续操作的前提。默认是OFF，CREATE EVENT会报错（比如提示“Event execution time is in the past”，其实跟时间无关）。
- 查状态：SHOW VARIABLES LIKE 'event_scheduler'; —— 返回OFF就必须处理
- 临时开（重启失效）：SET GLOBAL event_scheduler = ON;
- 生产环境必须永久开：在my.cnf的[mysqld]段加event_scheduler = ON，然后重启MySQL
- 注意云数据库（如阿里云RDS、腾讯云CDB）通常禁用该参数，此时EVENT不可用，只能改用外部crontab调用存储过程
清理逻辑必须封装进存储过程，不能裸写在EVENT里
EVENT只负责“到点唤起”，真正干活的得是存储过程——它能分批删、加延时、做预检、捕获错误、写日志。
- DELETE必须带WHERE + LIMIT，例如：DELETE FROM order_detail WHERE create_time
- create_time字段必须有B-tree索引，否则LIMIT也挡不住全表扫描和锁表
- 用WHILE循环+DO SLEEP(0.1)控制节奏，避免一次删太多拖垮业务
- 开头加预查：SELECT COUNT(*) INTO @cnt FROM ... WHERE ...，为0就直接退出，不空跑
- 结尾加错误捕获：DECLARE EXIT HANDLER FOR SQLEXCEPTION，把异常INSERT进audit_log表留痕
EVENT定义要避开常见陷阱
语法对不代表能跑通，时间表达式和单位写错，事件就等于没设。
- 周期任务必须用EVERY，单位用单数：EVERY 1 DAY ✅，EVERY 1 DAYS ❌
- 首次执行时间用CURRENT_TIMESTAMP，别用NOW()：STARTS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
- AT只适合一次性任务，清理类长期任务不能用AT
- 创建后查不到事件？SHOW EVENTS只显示当前USE的数据库下的事件，注意上下文
更稳妥的替代方案：外部定时调用
尤其在云环境或清理逻辑复杂时，用系统crontab + shell脚本调用存储过程，比纯EVENT更可控、可监控、易排错。
- 脚本里用mysql -u -p --defaults-file=~/.my.cnf -e "CALL clean_old_detail();"，密码不暴露在命令行
- crontab设在凌晨低峰期，比如0 2 * * *（每天2点）
- 脚本能捕获stderr，失败自动发邮件或写日志，EVENT做不到这点
- 兼容所有MySQL分支（RDS、TiDB、OceanBase等多数不支持EVENT）
