ALTER USER ... ACCOUNT LOCK是最快最安全的冻结方式，认证阶段即拦截新连接并报错ERROR 3118，不删库删表、不影响其他账号，但需确认该账号未被硬编码在中间件或定时任务中，否则引发服务中断。
直接执行 ALTER USER ... ACCOUNT LOCK 是最快、最安全的冻结方式，无需删库删表，也不影响其他账号——但必须确认该账号没被硬编码在中间件或定时任务里，否则会引发服务中断。
为什么 ACCOUNT LOCK 比 DROP USER 或密码重置更合适
冻结 ≠ 删除。离职员工账号往往还被应用连接池、监控脚本、ETL任务或备份工具引用。贸然 DROP USER 会导致 ORA-01940 类错误（MySQL 中表现为连接失败后持续重试），而单纯改密码可能被脚本自动轮询恢复。ACCOUNT LOCK 是 MySQL 5.7.6+ 原生支持的原子操作，认证阶段即拦截，不进权限校验流程，响应快、行为确定。
-
ACCOUNT LOCK状态下，所有新连接立即报错：ERROR 3118 (HY000): Access denied [] Account is locked - 已存在的空闲连接（如 HikariCP 的 idle 连接）不会被主动断开，但无法执行任何语句——这点和 Oracle 的
ALTER SYSTEM KILL SESSION不同，MySQL 不需要先杀会话 - 后续若需复用账号（如交接给新人），只需
ALTER USER ... ACCOUNT UNLOCK，比重建用户省事
冻结前必须查清的三件事
别只看用户名就动手。一个叫 'zhangsan'@'192.168.10.%' 的账号，可能是开发测试号，也可能是订单服务的数据库连接账号。必须交叉验证：
- 查它是否真被业务使用：
SELECT user, host, account_locked FROM mysql.user WHERE user = 'zhangsan';—— 注意account_locked字段是 MySQL 8.0 才有，5.7 只能靠注释或外部记录 - 查它的登录来源：
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_USER = 'zhangsan';（需开启 performance_schema） - 查是否有硬编码痕迹：在应用服务器上搜配置文件：
grep -r 'zhangsan' /opt/app/conf/ /etc/systemd/system/ 2>/dev/null；重点看application.yml、datasource.properties、systemctl cat *.service
执行冻结的最小安全操作集
不要在命令行里写密码，不要用 root 直连生产库做批量操作。按顺序执行：
- 用专用运维账号登录：
mysql -u dba_op -S /var/lib/mysql/mysql.sock - 锁定账号（注意主机名必须完全匹配）：
ALTER USER 'zhangsan'@'192.168.10.%' ACCOUNT LOCK; - 刷新权限使变更即时生效：
FLUSH PRIVILEGES;（MySQL 8.0.16+ 非必需，但低版本建议保留） - 验证是否生效：
mysql -u zhangsan -h 192.168.10.5 -p应立刻返回ERROR 3118
真正容易被忽略的是：冻结后要同步更新你的账号台账。很多团队只管“锁”，不管“记”——下次审计时发现台账里还标着“在职”，或者半年后有人误以为账号已失效而复用，反而埋下更大风险。
