MySQL全局写权限撤销：一个必须直面的“硬骨头”
当需要紧急锁定一个MySQL账户的写操作时，很多人的第一反应是执行一条“全局撤销”命令。但真相是，MySQL的权限体系里，压根就没有一个叫“全局写权限”的开关。这意味着，你无法像关灯一样，用一条命令就熄灭所有库的写入能力。那种试图用REVOKE INSERT, UPDATE, DELETE ... ON *.*来一键搞定的想法，往往会撞上冰冷的错误提示。
撤销所有数据库的写权限，不能靠 DROP USER 或 REVOKE ALL 一键搞定
问题出在哪儿？关键在于，REVOKE命令的生效逻辑，必须和当初GRANT授权时的对象与粒度严丝合缝。如果用户是通过GRANT ... ON *.*获得的高权限，那么权限信息就直接记录在了mysql.user这张核心表里。而当你执行REVOKE ... ON *.*时，MySQL默认不会去检查这张表，它只去mysql.db或mysql.tables_priv等表中寻找显式记录。这就导致了“明明有权限，却撤销不掉”的尴尬局面。
- 典型报错：你会看到
ERROR 1141 (42000): There is no such grant defined for user 'u' on host '%'，仿佛这个用户从未被授予过任何权限，尽管他正在对数据库进行写入。 - 核心症结：权限存储在多个表中，而
REVOKE指令的查询范围存在盲区。对于存储在mysql.user表中的账户级全局权限，常规的REVOKE命令无能为力。 - 第一步：先诊断，再下药：在动手前，必须确认权限的来源。执行下面的查询，看看那些写权限字段（Insert_priv, Update_priv等）是不是都是‘Y’：
SELECT Host, User, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Alter_priv FROM mysql.user WHERE User = 'your_user';
如果结果全是Y，那么恭喜你（或者说麻烦来了）——你面对的正是账户级全局权限。这种情况下，唯一彻底的办法就是直接修改mysql.user表，并刷新权限。
安全修改 mysql.user 表前必须停写 + 备份 + 显式重置
直接UPDATE mysql.user表是条“捷径”，但也是条“险路”。它绕过了MySQL的权限校验逻辑，一旦操作失误，比如写错了字段或者影响了root账户，后果可能是灾难性的。因此，一套严谨的操作流程至关重要。
- 进入维护模式：操作前，务必确保数据库实例已进入只读状态（
SET GLOBAL read_only = ON），并确认没有活跃的写事务。这是防止在修改过程中间出现权限状态不一致的保险栓。 - 备份！备份！备份！：这是你的回滚路线图。使用以下命令备份核心权限表：
mysqldump --single-transaction --databases mysql --tables user db tables_priv > mysql_user_backup.sql
- 精准打击，保留读权限：我们的目标是禁用写，而不是让业务完全中断。因此，更新语句需要精确地只将写相关字段设为‘N’，而保留
Select_priv等读权限：UPDATE mysql.user SET Insert_priv='N', Update_priv='N', Delete_priv='N', Create_priv='N', Drop_priv='N', Alter_priv='N', Create_tmp_table_priv='N', Lock_tables_priv='N' WHERE User='your_user' AND Host='%';
- 生效与验证：执行完
UPDATE后，必须运行FLUSH PRIVILEGES;来让变更立即生效。紧接着，用SHOW GRANTS FOR 'your_user'@'%';命令验证权限是否已按预期收回。
按库逐个 REVOKE 更安全，但耗时且容易漏掉新库
如果经过诊断，发现用户的权限并非来自mysql.user全局表，而是通过GRANT ... ON `db_name`.*逐库授予的，那么事情就相对简单一些。这时可以使用REVOKE命令逐个数据库回收权限。这种方式语义清晰，每一步操作都可审计，但它有两个天生的弱点：一是无法覆盖未来新建的数据库，二是当数据库数量成百上千时，手动操作极易出错和遗漏。
- 批量生成撤销语句：为了效率和准确性，可以通过查询
information_schema.schemata来动态生成针对所有业务库的REVOKE语句：SELECT CONCAT('REVOKE INSERT, UPDATE, DELETE, DROP, ALTER ON `', schema_name, '`.* FROM ''your_user''@''%'';') FROM information_schema.schemata WHERE schema_name NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys'); - 执行前的检查：生成的语句需要人工复核。特别注意数据库名中是否包含连字符等特殊符号，确保反引号使用正确，避免执行时出现
ERROR 1064语法错误。 - 警惕“新库”漏洞：逐库回收无法一劳永逸。只要后续有新建数据库（
CREATE DATABASE newdb），该用户在新库上默认并无权限。但是，如果该用户本身拥有CREATE权限，他就能自己创建数据库并获得隐式的全部权限（具体行为受sql_mode和MySQL版本影响）。因此，必须同步考虑回收其CREATE权限。
真正防住写操作，还得关掉 SQL_LOG_BIN 和禁止临时表
你以为收回了INSERT、UPDATE权限就万事大吉了？还差得远。MySQL中有些写操作路径，可以巧妙地绕过常规的库级（db）权限检查。
- 二进制日志的旁路：通过
SET SESSION sql_log_bin = OFF;关闭会话的二进制日志记录，可以防止写操作复制到从库。但这只是一个会话级设置，无法在全局强制，更多需要依靠应用层规范或中间件来控制。 - 临时表：一个隐蔽的通道：创建临时表的权限（
CREATE TEMPORARY TABLES）是独立存在的。如果未显式回收，用户依然可以创建临时表，并通过INSERT ... SELECT或SELECT ... INTO OUTFILE等方式间接实现数据写入或导出。因此，务必检查并执行：REVOKE CREATE TEMPORARY TABLES ON *.* FROM ...。 - 最后的防线：对于MySQL 5.7及以上版本，可以结合设置
read_only=ON和super_read_only=ON来强化实例级的只读属性。但请注意，这对拥有SUPER权限的用户（如root）是无效的。所以，一切又回到了原点：彻底清理账户本身的权限，才是治本之策。
说到底，MySQL的权限系统不是一个简单的开关阵列，而是一个层层叠加的状态机。直接修改mysql.user表固然快，但敲错一个字母就可能锁死整个账户；逐库REVOKE相对安全，可漏掉一个库就意味着前功尽弃。最稳妥的操作流程，永远始于用SELECT彻底摸清权限现状，终于FLUSH PRIVILEGES后的即时验证。在权限管理的世界里，谨慎从来不是多余的美德。
