可行但需开启event_scheduler，否则EVENT不执行；云数据库常禁用该功能，需外部调度；安全清理应避免锁表、误删和慢查询。
MySQL里用EVENT自动删过期敏感数据行不行
行，但得开event_scheduler，默认是关的。不开就等于写了定时任务却没启动调度器，SHOW EVENTS能看到定义，但压根不执行。
常见错误现象：SELECT @@event_scheduler返回OFF，或者连CREATE EVENT都报错“Event scheduler is disabled”。
- 先执行
SET GLOBAL event_scheduler = ON（需要SUPER权限） - 永久生效要改配置文件
my.cnf，加一行event_scheduler=ON，否则重启MySQL就又关了 - 注意：有些云数据库（如阿里云RDS、腾讯云CDB）禁用
event_scheduler，这时只能靠外部调度
怎么写一个安全的自动清理EVENT
核心是避免锁表、误删、慢查询拖垮实例。别直接DELETE FROM user_info WHERE create_time ——大表上没索引会全表扫描+锁住整个表几秒甚至几分钟。
- 必须确保
WHERE条件字段有索引，比如create_time或expire_at列建了B-tree索引 - 用
LIMIT分批删，比如每次删5000行，配合SLEEP(0.1)降低IO压力（EVENT里不能直接用SLEEP()，得包装进存储过程） - 别用
NOW()做判断基准，改用DATE_SUB(CURDATE(), INTERVAL 90 DAY)，避免跨天时区或事务时间点偏差 - 示例逻辑片段：
DELETE FROM sensitive_log WHERE expire_at < DATE_SUB(CURDATE(), INTERVAL 90 DAY) LIMIT 5000;
为什么不用crontab调用mysql命令更稳妥
因为EVENT跑在MySQL进程内，一旦SQL出错（比如字段名写错、权限不足、磁盘满），整个EVENT会停摆，且不会告警；而外部crontab可以捕获错误输出、发邮件、重试、记录日志。
- 适合场景：清理逻辑复杂（比如要先查再删再写审计日志）、需和其它系统联动（如通知Kafka）、或运行环境不允许开
event_scheduler - 关键点：用
mysql -u -p --execute="DELETE ..."时，密码别写在命令行里（会被ps看到），改用~/.my.cnf配[client]段 - 兼容性更好：RDS、TiDB、OceanBase等多数不支持EVENT，但都能跑shell脚本
敏感数据清除后要不要做归档或审计留痕
要。法律和审计通常要求“删了什么、什么时候删的、谁触发的”，纯DELETE不留记录，等于没证据。
- 删之前INSERT INTO audit_log SELECT ..., 'auto_cleanup', NOW() FROM sensitive_table WHERE ...
- 别用
TRUNCATE——它不走binlog（除非ROW格式+GTID），且无法回滚、不触发触发器、不记录单条删除明细 - 如果表启用了binlog，确认
binlog_format=ROW，否则基于语句的复制可能让从库执行失败
真正麻烦的是跨分片、跨库、带外键依赖的敏感表——这时候自动清理不是写个EVENT就能解决的，得先梳理数据生命周期和依赖链。
