撤销mysql用户全局权限必须执行revoke all privileges on . from 'user'@'localhost'并flush privileges，同时单独撤销grant option；权限分层叠加，仅删用户或 revoke 数据库级权限无效，须按最小权限原则重授并留痕可逆。
撤销 mysql 用户全局权限必须用 revoke all privileges on *.*
直接执行 revoke all privileges on *.* from 'user'@'localhost' 才算真正清空全局权限。很多人误以为删掉用户或只 revoke 数据库级权限就足够，其实不行——mysql 的权限是分层叠加的，全局权限不显式撤销，它就一直存在。
-
REVOKE SELECT ON mydb.* FROM 'user'@'localhost'只影响mydb，对其他库和全局操作（如SHOW DATABASES、CREATE USER）完全没作用 - 如果用户之前被授予过
GRANT OPTION，仅 revoke 权限还不够，必须额外执行REVOKE GRANT OPTION ON *.* FROM 'user'@'localhost'，否则他仍可能给自己加权 - 撤销后务必执行
FLUSH PRIVILEGES—— 虽然 MySQL 8.0+ 多数情况自动刷新，但某些连接复用场景下权限缓存未更新，会导致“明明 revoke 了却还能操作”的假象
重授权限前先确认最小必要范围，别直接 GRANT ALL PRIVILEGES
重授不是补回原来的样子，而是按当前业务需要重新评估。盲目 GRANT ALL PRIVILEGES ON *.* 等于把刚撤掉的权限又全还回去，白干一趟。
- 生产环境应严格遵循最小权限原则：比如只读服务只需
SELECT，后台任务可能加INSERT, UPDATE，但绝不给DROP或ALTER - 注意主机名匹配：
'user'@'10.20.%'和'user'@'%'是两个不同用户，revoke 时写错会漏掉目标；同样，grant 时若用'user'@'localhost'却从远程连，权限根本不起作用 - 列级权限（如
GRANT SELECT(id,name) ON app.users TO 'api'@'%'）虽精细，但运维成本高，除非审计强要求，否则优先用表级控制
权限重置失败的三个典型现象和对应检查点
命令没报错，但权限没变？常见原因不在语法，而在权限模型本身。
- 现象：“
REVOKE成功，但用户仍能CREATE DATABASE” → 检查是否遗漏了REVOKE CREATE DATABASE ON *.*，或者该用户是root或拥有SYSTEM_VARIABLES_ADMIN等高阶管理权限，这些不属于ALL PRIVILEGES范畴 - 现象：“新 grant 的权限在客户端不生效” → 不是没刷权限，而是客户端复用了旧连接；让应用重启连接池，或让用户断开重连，
SELECT USER(), CURRENT_USER()确认当前会话实际匹配的账号 - 现象：“撤销后
SHOW GRANTS还显示一堆权限” → MySQL 8.0+ 的角色（role）机制可能导致权限来自角色而非直接授予；用SELECT * FROM mysql.role_edges WHERE TO_HOST = 'localhost' AND TO_USER = 'user';查角色继承链
标准化流程的关键不是步骤多，而是每次操作都留痕可逆
所谓“标准化”，不是套模板，而是确保每一步都能被验证、被回滚、被审计。
- 执行前用
SHOW GRANTS FOR 'user'@'host';截图或记录原始权限，避免事后争议 - 撤销和重授尽量拆成独立语句，不要合并成一条
GRANT ... WITH GRANT OPTION后立刻REVOKE，中间出错难定位 - 所有操作建议通过自动化脚本执行（哪怕只是 shell + mysql -e），人工复制粘贴容易漏空格、错引号，尤其在
@'192\.168\.1\.100'这类带点号的 host 上
权限这事没有“做完就完”，真正麻烦的是跨版本迁移、主从权限同步不一致、以及开发临时要权限后忘了清理——标准化的本质，是让下次有人想改权限时，一眼看懂上次为什么这么设。
