MySQL中不能用GRANT直接“分配数据库”，必须明确权限类型、数据库名（如myapp_db.*）、用户及主机；需执行FLUSH PRIVILEGES生效，8.0+须先CREATE USER，推荐用角色管理权限。
直接给用户分配数据库权限的正确语法
MySQL 中不能用 GRANT 直接“分配数据库”，必须明确指定权限类型、数据库名（支持通配符）、用户和主机。最常见错误是漏写 ON database_name.* 或误用反引号包裹数据库名导致语法失败。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
标准授权命令结构是：
GRANT <privileges> ON <database>.<table> TO '<user>'@'<host>' [IDENTIFIED BY 'password'];
比如给用户 app_user 分配对 myapp_db 的全部操作权限：
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_user'@'localhost';
-
myapp_db.*表示该库下所有表；用*.* 则是所有库所有表（危险，慎用） - 必须执行
FLUSH PRIVILEGES;才能让权限立即生效（仅在修改系统表后需要，但养成习惯总没错） - 如果用户不存在，MySQL 5.7+ 默认不会自动创建，需先
CREATE USER；8.0+ 更严格，GRANT不再隐式建用户
只读权限怎么设才安全
生产环境给第三方或应用账号开只读，不能只写 SELECT 就完事——要防跨库查询、防元数据泄露、防锁表干扰。
推荐组合：
GRANT SELECT ON myapp_db.* TO 'report_user'@'10.20.%';
- 避免用
SELECT ON *.*，否则能查information_schema和其他业务库 - 主机限定用网段（如
'10.20.%'）比'%'更可控 - MySQL 8.0+ 可额外加
WITH GRANT OPTION控制是否允许转授，一般不加 - 注意：
SELECT权限本身不包含SHOW CREATE TABLE或SHOW INDEX，如需这些，得单独补SHOW VIEW
撤销权限后为什么还生效
撤销权限用 REVOKE，但常见现象是执行完 REVOKE 后旧连接仍能操作——这不是 bug，是 MySQL 权限缓存机制所致。
- 已建立的连接不会实时重载权限，直到断开重连
- 新连接会立即读取最新权限，所以测试时务必用新客户端连接验证
- 若要强制让当前所有连接失效，只能
KILL对应线程，或等其自然超时 - 撤销全部权限的写法是：
REVOKE ALL PRIVILEGES ON myapp_db.* FROM 'app_user'@'localhost';
MySQL 8.0 授权和老版本的关键差异
如果你在 8.0 环境下照搬 5.7 的授权语句，大概率报错。核心区别在用户创建与认证插件。
- 8.0 默认认证插件是
caching_sha2_password，而老客户端可能不支持，连不上就以为授权失败 - 显式创建用户必须带
IDENTIFIED WITH或指定密码：CREATE USER 'u'@'h' IDENTIFIED BY 'p'; -
GRANT不再自动创建用户，必须先CREATE USER，否则报错ERROR 1410 (42000): You are not allowed to create a user with GRANT - 角色（ROLE）成为权限管理主流方式，单库授权虽仍可用，但跨服务复用建议改用角色 +
SET DEFAULT ROLE
权限不是配完就一劳永逸的事，尤其涉及主机匹配、连接复用、认证插件这些点，稍不注意就会卡在“明明授了权却连不上/没效果”的环节。
