MySQL 8.0 不支持原生账号自动过期，必须用 CREATE USER + ALTER USER 组合模拟；实操需结合 COMMENT 标注、系统级 cron 脚本定期执行 ACCOUNT LOCK、最小权限授权及人工数据清理。
MySQL 8.0 不支持原生账号自动过期，必须用 CREATE USER + ALTER USER 组合模拟
MySQL 8.0 本身没有「账号生命周期」或「到期自动禁用」机制。所谓“定时过期”，本质是人为设定一个时间点，到时执行 ALTER USER ... ACCOUNT LOCK 或 DROP USER。临时外包账号的安全底线是：**不能依赖人肉提醒，必须可脚本化、可调度、可审计**。
实操建议：
- 创建账号时，用注释明确记录预期失效时间，例如：
COMMENT 'expires:2025-06-30;by:devops'（MySQL 8.0.22+ 支持COMMENT字段） - 避免用密码过期策略（
PASSWORD EXPIRE）代替账号锁定——密码过期后用户仍可登录（如使用缓存凭据、跳过密码验证的客户端），只是无法执行写操作，风险残留 - 账号名建议带标识，如
'dev_temp_john_202506'，便于后续按命名规则批量筛选
用系统级定时任务（cron）驱动账号清理，而非 MySQL 事件调度器
MySQL 的 EVENT 功能虽能定时执行 SQL，但它运行在数据库内，权限受限、无日志输出、失败不易捕获，且事件调度器本身可能被关闭（event_scheduler=OFF）。对账号生命周期这种关键操作，应交由操作系统级调度器控制。
实操建议：
- 写一个清理脚本
/opt/mysql/scripts/revoke_temp_users.sh，用mysql -u root -p... -e "ALTER USER 'xxx'@'%' ACCOUNT LOCK;"执行锁定 - 脚本开头加校验：查询
mysql.user表中account_locked = 'N'且comment含expires:且日期已过，再执行锁定 - cron 设为每天凌晨 2 点运行：
0 2 * * * /opt/mysql/scripts/revoke_temp_users.sh >> /var/log/mysql/temp_user_cleanup.log 2>&1 - 务必测试脚本在无交互、无 TTY 环境下的执行效果（避免因
mysql命令读取 .my.cnf 凭据失败而静默退出）
临时账号权限必须严格限制在最小必要范围，且禁止授予 GRANT OPTION
外包人员一旦获得 GRANT OPTION，就能给自己或他人提权，彻底绕过权限隔离。即使账号“过期”了，若此前已导出数据或创建了新账号，后果不可逆。
实操建议：
- 建号后立即用
REVOKE GRANT OPTION ON *.* FROM 'dev_temp_john_202506'@'%';清除该权限（默认不开启，但需确认） - 只授权具体库表，例如：
GRANT SELECT, INSERT, UPDATE ON `project_x`.* TO 'dev_temp_john_202506'@'%';，绝不用ALL PRIVILEGES - 禁止授权
mysql、sys、information_schema等系统库（即使只读） - 连接来源限制到 IP 段：
'dev_temp_john_202506'@'192.168.10.%'，而非通配符'%'
账号锁定 ≠ 数据删除，外包交接前必须人工确认敏感数据残留
ACCOUNT LOCK 只阻止登录，不删除账号、不清理其创建的对象（如临时表、存储过程、事件）、也不清除其写入的数据。如果外包曾建过 TEMP_LOGS_202504 表并插入调试数据，这些内容仍留在库里。
容易被忽略的点：
- 锁定账号后，要人工检查
SHOW CREATE DATABASE和SELECT table_name FROM information_schema.tables WHERE table_schema = 'project_x' AND table_comment LIKE '%temp%'; - 外包使用的数据库账号若拥有
CREATE TEMPORARY TABLES权限，其会话级临时表虽自动销毁，但若用的是普通表模拟临时表（常见于 ORM），则不会自动清理 - 若外包有
EVENT或TRIGGER权限，需额外检查information_schema.EVENTS和information_schema.TRIGGERS中是否残留非预期对象
