应执行SELECT host, user, plugin FROM mysql.user WHERE Insert_priv = 'Y' AND Update_priv = 'Y' AND Delete_priv = 'Y' AND Create_priv = 'Y' AND Drop_priv = 'Y';该语句精准筛选具备全局DML/DDL写权限的账户，严格匹配字符串'Y'，并附带认证插件信息用于安全评估。
查 mysql.user 表中 Insert_priv、Update_priv、Delete_priv、Create_priv、Drop_priv 全为 'Y' 的账户
MySQL 的全局写权限不靠单条语句判断，而是看 mysql.user 表里对应字段是否全为 'Y'。注意：这些字段是字符串值，不是布尔，必须严格匹配 'Y'（大小写敏感），'y' 或空值、'N' 都不算。
直接查最准：
SELECT host, user, plugin FROM mysql.user WHERE Insert_priv = 'Y' AND Update_priv = 'Y' AND Delete_priv = 'Y' AND Create_priv = 'Y' AND Drop_priv = 'Y';
- 这个查询只覆盖「全局粒度」的写权限，不包含库级（
mysql.db）或表级（mysql.tables_priv）授权 -
plugin字段顺带查出认证方式，便于识别是否使用弱插件（如mysql_native_passwordvscaching_sha2_password） - 若用
SHOW GRANTS FOR 'u'@'h';手动验证，结果可能被角色（ROLE）间接叠加，而mysql.user只反映直连授权，更可控
别漏掉 root 和匿名用户这类默认高危账户
root 账户常被忽略——它不一定叫 'root'，也可能绑定在 'localhost'、'127.0.0.1'、'::1' 等多个 host 上，且部分实例存在无用户名的匿名账户（user = ''），它们只要权限字段全为 'Y'，就是隐形炸弹。
检查时务必加宽松匹配：
SELECT host, user, authentication_string, plugin FROM mysql.user WHERE (user = 'root' OR user = '') AND Insert_priv = 'Y' AND Update_priv = 'Y' AND Delete_priv = 'Y';
- 匿名用户（
user = ''）在旧版本 MySQL 中默认允许登录，新版本虽默认禁用，但升级后残留仍可能生效 -
authentication_string字段可快速识别是否为空密码或弱哈希（如长度过短的mysql_native_password哈希）
注意 GRANT OPTION 带来的隐式提权风险
光有 DML/DDL 权限还不够——如果账户还拥有 Grant_priv = 'Y'，它就能把自己或他人权限再扩大，属于“权限放大器”。这类账户即使当前没被滥用，也应视为高危。
建议合并筛查：
SELECT host, user, Grant_priv, Super_priv FROM mysql.user WHERE Insert_priv = 'Y' AND Update_priv = 'Y' AND Delete_priv = 'Y' AND (Grant_priv = 'Y' OR Super_priv = 'Y');
-
Super_priv允许执行KILL、修改全局变量等操作，常与写权限组合构成完全控制 - 不要依赖
SHOW GRANTS输出判断GRANT OPTION，因为输出格式不统一（例如 8.0+ 可能显示为WITH GRANT OPTION，但字段值才是唯一事实）
权限字段在 MySQL 8.0+ 的兼容性变化
MySQL 8.0 引入了角色（ROLE）和动态权限（如 CONNECTION_ADMIN），但 mysql.user 中的传统权限字段（Insert_priv 等）依然有效且优先级高于角色——只要这些字段是 'Y'，角色是否启用不影响其实际能力。
不过要注意：
- 8.0+ 默认关闭
old_passwords，但若手动设为1，可能导致密码哈希降级，配合高权限账户更危险 -
max_user_connections、max_questions等限制字段为 0 表示不限制，和权限字段无关，但属于加固点，顺手查一下没坏处
真正难处理的是那些通过角色间接获得全库写权限的账户——它们在 mysql.user 里对应字段可能是 'N'，但 SELECT * FROM mysql.role_edges; + mysql.role_tables_priv 组合才能厘清。这种场景需要额外分析，不能只靠单表扫描。
