生产环境不能直接DROP USER，因存在三大卡点：一是不自动终止活跃连接，导致应用异常；二是若该用户为视图/存储过程DEFINER，MySQL 8.0+会报ERROR 3725中断执行；三是ProxySQL或中间件硬编码该账号将引发Unknown user错误，排查困难。
直接删账号风险高，先锁再撤权限最稳妥。DROP USER看似彻底，但可能触发应用重连风暴、DEFINER报错或中间件硬编码失效；而单纯REVOKE又留角色和USAGE，权限没真清空。
为什么不能直接 DROP USER 'alice'@'10.20.30.%'
三个现实卡点会让你停在半路：
- 该用户正有活跃连接 → DROP USER 不会自动 KILL，应用可能持续报错或行为异常
- 被设为某视图/存储过程的
DEFINER→ MySQL 8.0+ 会直接报错ERROR 3725 (HY000)，命令中断 - ProxySQL 或应用配置里写了这个账号 → 删完后客户端连不上，报的是
Unknown user而非权限拒绝，排查路径变长
所以生产环境第一步永远是“软隔离”：锁账号，阻断新连接，留出验证和清理窗口。
批量锁定离职账号必须用 ALTER USER，不是 UPDATE mysql.user
UPDATE mysql.user SET account_locked = 'Y' 是典型伪操作——字段改了，MySQL 内部状态不更新，重启或权限刷新后就回滚。真正生效的只有：
- 逐条执行
ALTER USER 'alice'@'10.20.30.%' ACCOUNT LOCK; - Host 必须完整匹配，
'alice'@'%'和'alice'@'10.20.30.%'是两个账号 - 通配符
%只能在 Host 字段里出现，不能用于ALTER USER的模式匹配（比如'%'@'%'语法错误） - 生成语句推荐用
SELECT CONCAT('ALTER USER `', User,'`@`', Host,'` ACCOUNT LOCK;') FROM mysql.user WHERE User IN ('alice','bob');，反引号防特殊字符报错
锁住后实测登录：mysql -u alice -p -h your-db，输任意密码都应立刻失败；老版本（5.7.6+）报 ERROR 1045 (28000)，和输错密码一样，只能靠重连验证。
撤销权限要分两步：先解绑角色，再撤全局显式权限
REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'alice'@'10.20.30.%' 看似干净，其实只动了显式授权，三处残留必查：
- 角色没动：如果之前
GRANT 'analyst_role' TO 'alice'@'10.20.30.%'，角色里的所有权限继续生效 → 先跑REVOKE 'analyst_role' FROM 'alice'@'10.20.30.%'; - USAGE 权限隐式存在：撤完后
SHOW GRANTS FOR 'alice'@'10.20.30.%'还会返回GRANT USAGE ON *.* TO ...，这是合法且无法撤销的连接基础权限 - 旧连接不生效：已连上的会话仍保持原权限，直到断开重连 → 验证必须新开连接，不能看当前 session 的
SHOW GRANTS
执行前确认你有权限：SHOW GRANTS FOR CURRENT_USER; 至少要有 CREATE USER ON *.* 或 UPDATE ON mysql.*，否则直接 ERROR 1227。
最后一步才是 DROP USER，但得先手动清残留权限表
MySQL 官方文档说 DROP USER “自动清理所有权限表”，但实际中 mysql.db、mysql.tables_priv 仍可能残留旧记录，导致重建同名用户时“意外继承权限”。安全做法是：
- 先查残留：
SELECT * FROM mysql.db WHERE User = 'alice'; SELECT * FROM mysql.tables_priv WHERE User = 'alice'; - 手动删干净：
DELETE FROM mysql.db WHERE User = 'alice'; DELETE FROM mysql.tables_priv WHERE User = 'alice'; FLUSH PRIVILEGES; - 再执行
DROP USER 'alice'@'10.20.30.%';（MySQL 8.0+ 支持DROP USER IF EXISTS避免不存在时报错） - 删完立刻查
SELECT User, Host FROM mysql.user WHERE User = 'alice';，结果为空才算真正消失
真正容易被忽略的点是：Host 匹配精度。你删的是 'alice'@'10.20.30.%'，但用户实际连的是 'alice'@'10.20.30.123' —— MySQL 认为这是不同账号，得查 information_schema.PROCESSLIST 确认真实 Host 值再操作。
