必须直接UPDATE mysql.user表并FLUSH PRIVILEGES才能彻底撤销全局写权限，因REVOKE无法回收mysql.user中存储的账户级权限；操作前须停写、备份、验证，且仅禁用写权限字段保留读权限。
撤销所有数据库的写权限，不能靠 DROP USER 或 REVOKE ALL 一键搞定
MySQL 的权限体系里没有“全局写权限”这个概念，REVOKE INSERT, UPDATE, DELETE, DROP, ALTER ON *.* 看似合理，但实际会失败——因为 *.* 范围下，MySQL 不允许直接回收未显式授予过的权限组合，尤其当用户是通过 GRANT ... ON *.* 获得的高权限时，REVOKE 必须严格匹配当初 GRANT 的对象和权限粒度。
- 常见错误现象：
ERROR 1141 (42000): There is no such grant defined for user 'u' on host '%'，即使该用户明明能写所有库 - 根本原因：MySQL 权限存储在
mysql.tables_priv、mysql.db、mysql.proxies_priv等多张表中，而REVOKE只查mysql.db和mysql.tables_priv中显式记录的条目；如果当初用的是GRANT ... ON *.*，权限记在mysql.user表里，但REVOKE ... ON *.*默认不查这张表 - 正确做法是先确认权限来源：
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），必须用UPDATE mysql.user配合FLUSH PRIVILEGES
安全修改 mysql.user 表前必须停写 + 备份 + 显式重置
直接 UPDATE mysql.user 是唯一能彻底关闭全局写权限的方式，但它绕过了权限校验逻辑，风险极高——写错字段或漏刷权限会导致用户完全失访，甚至影响 root 登录（如果误操作了 root 行）。
- 操作前必须确保：MySQL 已进入维护模式（
SET GLOBAL read_only = ON），且无活跃写事务；否则可能引发权限状态不一致 - 备份权限表：
mysqldump --single-transaction --databases mysql --tables user db tables_priv > mysql_user_backup.sql
- 只禁用写相关字段，保留读权限（避免业务全挂）：
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='%';
- 切记执行：
FLUSH PRIVILEGES，否则变更不生效；FLUSH后建议立刻验证：SHOW GRANTS FOR 'your_user'@'%';
按库逐个 REVOKE 更安全，但耗时且容易漏掉新库
如果用户权限不是来自 mysql.user，而是通过 GRANT ... ON `db_name`.* 显式授予的，那可以用 REVOKE 逐库回收。这种方式语义清晰、可审计，但有两个硬伤：无法覆盖未来新建的库，且对上百个库的手动操作极易出错。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 生成批量
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权限，就能自己建库并获得隐式ALL权限（取决于sql_mode和 MySQL 版本），所以必须同步回收CREATE权限
真正防住写操作，还得关掉 SQL_LOG_BIN 和禁止临时表
仅控权限还不够。有些写行为不走权限检查路径：比如通过 LOAD DATA INFILE 写入、用 INSERT ... SELECT 从其他库导数据、或利用临时表做中间计算再落盘。这些都可能绕过 db 级权限限制。
- 禁用日志写入（防止主从扩散）：
SET SESSION sql_log_bin = OFF;—— 但这只是会话级，无法全局强制，只能靠应用层约束 - 临时表权限独立控制：
CREATE TEMPORARY TABLES权限单独存在，必须显式REVOKE CREATE TEMPORARY TABLES ON *.*，否则用户仍可建临时表+INSERT+SELECT INTO OUTFILE 绕过 - 最严方案：配合
read_only=ON+super_read_only=ON（5.7+），但这两项对root或SUPER用户无效，所以最终还得回到账户级权限清理本身
权限系统不是开关，是层层叠加的状态机。改 mysql.user 字段快，但错一个字母就锁死；逐库 REVOKE 安全，但漏一个库就白干。真正稳的操作，永远始于 SELECT 查清现状，止于 FLUSH PRIVILEGES 后的即时验证。
