mysql中没有原生“账号锁定”机制，实际通过alter user重置密码、revoke撤销权限或drop user彻底删除来阻断访问；需注意密码策略、host匹配、认证插件及代理用户等细节。
MySQL中没有“账号锁定”概念，只有禁用或删除
MySQL本身不提供类似操作系统那种 LOCK ACCOUNT 的账户锁定机制。所谓“锁定离职员工账号”，实际是通过权限控制或身份验证干预来实现访问阻断。最直接有效的方式是重置密码、撤销权限，或彻底删除用户——而不是幻想执行一条“lock user”命令。
用 ALTER USER ... IDENTIFIED BY 强制重置密码
这是最常用且低风险的操作：保留账号结构（如权限、历史记录），但让原密码失效。注意 MySQL 8.0+ 要求密码满足策略（如长度、字符类型），否则会报错 ERROR 1819 (HY000)。
实操建议：
- 执行
ALTER USER 'zhangsan'@'%' IDENTIFIED BY 'xK9#qL2$mN!';（密码需含大小写字母+数字+特殊符号） - 若想设为空密码（仅限测试环境且
validate_password插件未启用），用IDENTIFIED WITH mysql_native_password BY '' - MySQL 5.7 不支持空密码，且默认使用
mysql_native_password插件；8.0 默认是caching_sha2_password，客户端兼容性差时可显式指定插件
用 DROP USER 彻底移除账号（推荐长期离职业务）
比禁用更干净：不仅删账号，还自动回收其所有全局/库级权限。但要注意——DROP USER 不影响已存在的数据库对象（如表、视图），也不清理应用连接池里的旧配置。
常见错误现象：
- 执行
DROP USER 'lisi'@'192.168.1.%';后，应用仍连得上？检查是否还有'lisi'@'localhost'或'lisi'@'%'等其他 host 匹配项 - 误删了同名但不同 host 的账号（如运维用的
'admin'@'10.0.0.%'），建议先查SELECT User, Host FROM mysql.user WHERE User = 'lisi'; - MySQL 8.0+ 中
DROP USER不再隐式调用FLUSH PRIVILEGES，但实际已自动生效，无需手动刷
权限回收后仍能登录？重点检查 authentication_string 和代理用户
有时即使撤销权限、重置密码，用户仍能登录——大概率是因为账号启用了代理认证（proxy user）或密码字段被绕过。比如 authentication_string 字段为空，且 skip-grant-tables 曾被启用过；或用户被授予了 PROXY 权限，由另一个账号代为认证。
排查步骤：
- 查真实认证方式：
SELECT User, Host, plugin, authentication_string FROM mysql.user WHERE User = 'wangwu'; - 若
plugin是auth_socket或unix_socket（常见于 Ubuntu 自带 MySQL），则密码无效，靠系统用户认证——必须删掉该账号或改用mysql_native_password - 检查代理关系：
SELECT * FROM mysql.proxies_priv WHERE User = 'wangwu';，如有结果，需用REVOKE PROXY ON ''@'' FROM 'wangwu'@'%';解除
真正麻烦的不是操作本身，而是账号体系混乱：同一人多个 host、混用 plugin、权限分散在不同 role、甚至跨实例共享凭证。离职处理必须结合账号盘点和最小权限原则，否则重置一个密码，可能还有三个备用入口开着。
