grant语句中数据库名通配符必须用反引号包裹，如dp%.*，否则会被当作字面库名；%匹配任意长度字符串，_仅匹配单个字符，且仅对数据库名有效，不支持跨库混写权限。
GRANT 通配符在数据库名中怎么写才有效
MySQL 的 GRANT 语句支持对数据库名使用 % 和 _ 通配符，但仅限于数据库名部分（即 ON db_name.* 中的 db_name），且必须用反引号包裹，否则会报语法错误或被当作字面量处理。
常见错误是写成 GRANT SELECT ON dp%.* TO 'user'@'%' —— 这里 dp% 没加反引号，MySQL 会尝试查找名为 “dp%” 的实际数据库，而不是做模式匹配。
- 正确写法：
GRANT SELECT ON `dp%`.* TO 'user'@'%' - 反引号不是可选的：含通配符的数据库名必须用
`包裹，哪怕没特殊字符 -
%匹配任意长度字符串（包括空），_只匹配单个字符；例如`project_202_`匹配project_2024、project_2026，但不匹配project_202 - 通配符只在 GRANT 时生效，运行时不会动态扩展——新增的匹配库自动获得权限，无需重新 GRANT
给多个数据库授不同权限，不能只靠一条 GRANT
一条 GRANT 语句只能指定一组权限（如 SELECT, INSERT）作用于一个数据库模式（如 `app_%`.*）。如果你要让同一个用户对 sales 库有 SELECT，对 log 库有 INSERT, UPDATE，就必须分两条写：
GRANT SELECT ON sales.* TO 'reporter'@'10.20.%'GRANT INSERT, UPDATE ON log.* TO 'reporter'@'10.20.%'
试图合并成 GRANT SELECT ON sales.*, INSERT ON log.* TO ... 是语法错误。MySQL 不支持跨库混写权限类型。另外注意：两次 GRANT 针对的是同一用户+主机组合，权限会叠加，不是覆盖。
为什么授权后应用还是报 Access denied
最常被忽略的不是语法，而是主机名匹配逻辑。MySQL 把 'user'@'localhost' 和 'user'@'127.0.0.1' 当作两个完全独立的账号，权限互不影响。
- 如果应用从本地用 IP 连接（如
mysql -h 127.0.0.1），但你只给了'user'@'localhost'权限 → 权限不生效 - 如果应用从远程连（如
192.168.5.100），而你只授权了'user'@'localhost'或'user'@'127.0.0.1'→ 同样失败 - 检查实际连接账号：登录后执行
SELECT CURRENT_USER();，它返回 MySQL 实际匹配到的'user'@'host'，不是你登录用的用户名 -
FLUSH PRIVILEGES在 MySQL 5.7+ 通常不需要——正常 GRANT 会自动重载权限表；只有直接改mysql.db等系统表后才需手动刷新
通配符授权的安全风险和替代思路
用 `project_%`.* 授权看似省事，但隐含两个现实问题：一是未来新建的库只要名字匹配就自动获得权限，可能超出预期；二是无法为其中某个库单独收权，除非用 REVOKE 精确到库名（而通配符本身不能用于 REVOKE）。
更可控的做法是结合角色（MySQL 8.0+）或脚本化管理，但在 MySQL 5.7 下建议：
- 优先用明确库名批量生成 GRANT 语句（比如从
SHOW DATABASES LIKE 'project_%'结果拼接） - 避免用
*.*或`%`.*，尤其是生产环境——这等于开放所有现有及未来库 - 若真需动态适配，至少限制主机范围，比如只允
'dev'@'192.168.10.%'，而非'dev'@'%'
通配符是快捷键，不是安全开关；它省下的那几行 SQL，往往要用额外的权限审计和故障排查来还。
