安全删除非活跃用户需用带事务和分批机制的存储过程：先按 last_login_time<90 天且 status!=’pending’ 筛选，SELECT COUNT 预估再 DELETE；用 LIMIT 1000+WAIT 分批删，确保 last_login_time 有索引；删后执行 OPTIMIZE TABLE 或 ALTER TABLE ENGINE=InnoDB 释放空间；禁用事件调度器，改用 cron 调用并记录 job_log。
如何用存储过程安全删除非活跃用户
直接删数据有风险，必须加条件限制和事务保护。核心是定义“非活跃”——不能只看注册时间，得看最近一次登录或操作时间，否则会误删刚注册还没来得及登录的用户。
-
DELETE FROM users必须搭配WHERE last_login_time < DATE_SUB(NOW(), INTERVAL 90 DAY)这类明确的时间窗口判断 - 务必排除
status = 'pending'或is_verified = 0的用户，这类账号可能只是没完成邮箱验证，不是真不活跃 - 建议先用
SELECT COUNT(*)统计将被删除的数量，确认无异常再执行DELETE - 整个过程要包在
BEGIN …… END和START TRANSACTION里，出错能回滚
MySQL 存储过程中怎么避免锁表太久
大表删数据容易阻塞其他读写，尤其在高并发业务库中。关键不是“能不能删”，而是“怎么删得轻一点”。
- 别一次性删几万行，用
LIMIT 1000分批删，配合WHILE循环 - 每次删完加
DO SLEEP(0.1)（需启用mysql.sys或自定义函数），让出 CPU 和 IO 资源 - WHERE 条件字段（如
last_login_time）必须有索引，否则全表扫描 + 锁表 = 雪崩 - 避免在高峰期运行，可用
SELECT HOUR(NOW()) NOT IN (9,10,11,14,15)控制执行时段
为什么 DELETE 后磁盘空间没释放
MySQL 的 InnoDB 表删完数据，空间默认不还给操作系统，只在表内标记为可复用。这常被当成“没删成功”，其实是机制问题。
- 执行
OPTIMIZE TABLE users可重建表并释放空间，但会锁表，生产环境慎用 - 更稳妥的是
ALTER TABLE users ENGINE=InnoDB，效果等同OPTIMIZE，但兼容性更好 - 如果表太大，考虑归档：先
INSERT INTO users_archive SELECT * FROM users WHERE ……，再删原表数据 - 长期看，建议开启
innodb_file_per_table = ON，否则所有表共享一个 ibdata1，删了也白删
定时执行该存储过程的可靠方式
MySQL 事件调度器（Event Scheduler）看着方便，但线上环境故障率高、日志难查，不如交给外部调度。
- 禁用
CREATE EVENT，它依赖event_scheduler = ON，而这个参数重启后可能失效 - 用系统级
cron调mysql -u user -p'pass' -e "CALL clean_inactive_users()"，失败时能发邮件告警 - 存储过程内部加
INSERT INTO job_log记录每次执行的start_time、deleted_count、error_msg - 别在存储过程中写
DROP TABLE或TRUNCATE，这类操作无法回滚，一旦误触发就不可逆
真正麻烦的不是写 SQL，而是确认“谁算非活跃”——产品、运营、法务对这个定义经常不一致，上线前必须拿真实数据样本对齐口径，不然删错了没法补。
