mysql新建用户默认仅有usage权限，但为防隐式权限残留或元数据泄露，须执行create user后立即revoke all privileges on .，再显式授予最小必要权限，并额外revoke select on information_schema.*以阻断元数据访问。
应用账号不该用 root 或 sa，也不该靠“记得没给高危权限”来赌安全——MySQL 的权限模型是显式授予、隐式拒绝，但配置稍有偏差就会留出意料之外的通道。
CREATE USER 后必须立刻 REVOKE ALL
MySQL 新建用户默认只有 USAGE 权限（即能连上但干不了任何事），但这不等于“干净”。某些旧版本或特殊部署下，可能残留隐式权限；更常见的是后续 GRANT 操作叠加出意外能力。所以标准动作是：
- 先执行
CREATE USER 'app_user'@'10.20.30.%' IDENTIFIED BY 'strong_password_123'; - 紧接着执行
REVOKE ALL PRIVILEGES ON *.* FROM 'app_user'@'10.20.30.%';（注意：不是REVOKE ALL，必须带ON *.*） - 再逐条
GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.`orders` TO 'app_user'@'10.20.30.%';
漏掉 REVOKE ALL 这步，就可能让账号继承 mysql 系统库的默认可读性（尤其在老版本中），或者因权限缓存导致后续 GRANT 行为不可预测。
为什么 SHOW GRANTS 显示的权限和实际行为不一致
你执行 SHOW GRANTS FOR 'app_user'@'10.20.30.%'; 看到只有 SELECT 和 INSERT，但应用却能查 information_schema.tables——这不是权限配置错了，而是 MySQL 默认允许所有账号读取元数据。
- MySQL 8.0.29+ 可设
show_compatibility_56=OFF并配合skip_show_database（已废弃），但更可靠的是显式回收：REVOKE SELECT ON information_schema.* FROM 'app_user'@'10.20.30.%'; - 这条
REVOKE需要执行者本身有SUPER权限，普通 DBA 账号未必具备，得提前确认权限链 - 老版本（
GRANT 时 ON *.* 是最危险的语法糖
写 GRANT SELECT ON *.* TO 'app_user'@'10.20.30.%'; 看似方便，实则等同于把整套 MySQL 当成裸机交出去。哪怕只漏了一次，攻击者就能执行 SELECT * FROM mysql.user; 获取哈希，或用 SELECT LOAD_FILE('/etc/passwd');（若未禁用 FILE 权限）。
- 必须精确到库表：用
GRANT SELECT ON `app_db`.`users` TO ...，而不是app_db.*，除非真需要操作该库全部表 - 如果只需要某几张表，就别用通配符；字段级权限虽少用，但对含身份证号的列值得考虑：
GRANT SELECT (id, name) ON `app_db`.`users` TO ... -
GRANT OPTION绝对禁止：它允许账号把权限转授出去，形成权限扩散链，监控账号或 ORM 自动建表脚本一旦误配，后果严重
权限生效后仍报错？先看连接池和 host 匹配
执行完 GRANT 立刻测试失败，大概率不是权限没生效，而是账号没被正确匹配到。
- MySQL 按
'user'@'host'组合精确匹配，'app_user'@'10.20.30.%'和'app_user'@'%'是两个独立账号，后者优先级更低但常被遗忘 - 连接池复用旧连接：有些驱动（如 older mysql-connector-java）不会在权限变更后自动重认证，需重启应用或清空连接池
- 本地连接用
localhost和127.0.0.1是不同 host，'app_user'@'localhost'无法从远程用127.0.0.1连入，反之亦然
真正麻烦的不是配置多难，而是权限状态分散在多个地方：系统表、连接池缓存、host 解析逻辑、甚至 TLS 配置（REQUIRE SSL 不加的话，中间人可能劫持明文密码）。每次上线前，务必用该账号从真实应用节点直连测试，别只信 SHOW GRANTS 输出。
