GRANT语句需精确指定库表名（如mydb.users）并用反引号包裹特殊字符表名，执行后常规情况自动生效，但直接操作系统表需FLUSH PRIVILEGES；撤销权限应优先用REVOKE而非DROP USER以避免配置丢失。
如何用 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 提权。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
真正的隔离必须落在权限层：没给 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 的残留权限——这两处查起来费劲，修起来要停服验证。
