如何用 GRANT 语句精确授权给 MySQL 用户
MySQL 的权限控制靠
GRANT实现，但直接写
GRANT SELECT ON *.*会过度放权。真正限制到「某个库 + 某张表」，必须明确写出数据库名和表名，且注意反引号包裹含特殊字符的名称。
常见错误是漏掉数据库名、误用通配符、或在未
FLUSH PRIVILEGES的情况下以为权限已生效。
GRANT SELECT, INSERT ON mydb.users TO 'appuser'@'10.20.30.%'—— 只允许查、插
mydb库下的
users表 若表名含短横线（如
log-2024），必须写成
mydb.`log-2024`，否则报错
ERROR 1064 (42000)执行完
GRANT后，记得运行
FLUSH PRIVILEGES（仅当直接操作
mysql系统表时才强制需要；常规
GRANT一般自动刷新）
撤销权限时为什么 DROP USER 不等于 REVOKE
DROP USER 'appuser'@'10.20.30.%'会彻底删除用户及其所有权限记录；而
REVOKE SELECT ON mydb.users FROM 'appuser'@'10.20.30.%'只收回指定权限，用户仍可登录、仍保有其他授权。
生产环境误删用户比误撤权限更难回滚——因为密码、主机限制、资源限制等配置全丢，且无法从
mysql.user表还原明文密码。 优先用
REVOKE收紧权限，而不是反复
DROP/CREATE USER检查当前权限用
SHOW GRANTS FOR 'appuser'@'10.20.30.%'，别依赖记忆
REVOKE ALL PRIVILEGES ON mydb.* FROM 'appuser'@'10.20.30.%'不会影响其他库权限，安全可控
WHERE 条件不能替代表级权限
有人试图用视图 +
WHERE user_id = CURRENT_USER()隐藏数据，但这不等于权限隔离。只要用户有底层表的
SELECT权限，就能绕过视图直查原表，甚至用
UNION SELECT提权。
真正的隔离必须落在权限层：没给
mydb.orders表的权限，用户连
DESCRIBE mydb.orders都会报
ERROR 1142 (42000): SELECT command denied。 视图适合逻辑封装，不是权限边界 敏感表（如
mysql.user、
information_schema下部分表）默认禁止普通用户访问，不要手动开放 MySQL 8.0+ 支持角色（
CREATE ROLE），可先授权给角色再分配角色给用户，便于批量管理
host 白名单比 % 更安全，但要注意 DNS 解析风险
写
'appuser'@'10.20.30.%'比
'appuser'@'%'安全得多，但若 MySQL 开启了
skip_name_resolve=OFF（默认），它会对客户端 IP 做反向 DNS 查询，可能因 DNS 延迟或污染导致连接失败或匹配错误 host。
最稳妥的做法是：关掉 DNS 解析（设
skip_name_resolve=ON），然后全部用 IP 或 CIDR 写死 host；如果必须用域名，确保内网 DNS 稳定且无缓存污染。 检查当前设置：
SELECT @@skip_name_resolve，返回 1 表示已关闭 host 字符串中
%匹配任意长度字符串，
_只匹配单个字符，别混淆 MySQL 不支持 CIDR 写法（如
10.20.30.0/24），只能用
10.20.30.%或逐条授权
权限粒度越细，
mysql.db和
mysql.tables_priv表里的记录越多，但不会影响查询性能；真正容易出问题的是 host 匹配逻辑和未及时
REVOKE的残留权限——这两处查起来费劲，修起来要停服验证。
