MySQL中授库级权限前须确认用户存在，否则GRANT静默失败或报错；需用SELECT User,Host FROM mysql.user;核对用户及Host精确匹配；不存在则先CREATE USER；GRANT语法必须为ON db_name.，不可省略.；权限不跨库继承，系统库无法通过库级授权访问。
直接给库级权限前先确认用户是否存在
MySQL 中给库级权限的前提是目标用户已存在，否则 GRANT 会静默失败（5.7+ 默认行为）或报错。用 SELECT User, Host FROM mysql.user; 查看已有用户，注意 Host 值必须完全匹配——'user'@'localhost' 和 'user'@'127.0.0.1' 是两个不同用户。
如果用户不存在，先用 CREATE USER 显式创建，例如：
CREATE USER 'app_rw'@'192.168.1.%' IDENTIFIED BY 'strong-pass-2024';
GRANT 语句必须指定明确的数据库名和权限组合
库级权限作用于单个数据库（schema），语法为 GRANT priv_type ON db_name.* TO user。不能省略末尾的 .*，写成 ON db_name 会被 MySQL 当作表名处理，报错 ERROR 1144 (42000): Wildcard denied for database。
常见权限组合建议：
-
SELECT, INSERT, UPDATE, DELETE：适用于应用只读写业务库，不碰系统表 -
SELECT, EXECUTE：适合只调用存储过程/函数的只读账号 - 避免直接授
ALL PRIVILEGES，即使在测试库也应最小化
示例（授予读写权限）：
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_rw'@'192.168.1.%';
执行 GRANT 后必须 FLUSH PRIVILEGES 吗？
不需要。MySQL 5.7.6+ 及所有 8.0 版本中，GRANT 语句会自动刷新权限缓存。手动执行 FLUSH PRIVILEGES 不但多余，还可能掩盖权限未生效的真实原因（比如用户 Host 不匹配、SQL 拼写错误等）。
验证权限是否生效，用目标用户连接后执行：
SHOW GRANTS FOR CURRENT_USER;或者
SHOW GRANTS FOR 'app_rw'@'192.168.1.%';
注意：CURRENT_USER() 返回的是认证用户（即实际匹配的 'user'@'host'），而 USER() 返回客户端声明的用户名，二者可能不同。
权限继承与跨库访问的边界容易被忽略
库级权限严格限定在指定数据库内，不会继承到新创建的库，也不会穿透到其他库的同名表。例如：GRANT SELECT ON sales.* 对 inventory.orders 完全无效。
如果应用需要跨多个业务库操作，必须逐个授权：
GRANT SELECT ON sales.* TO 'report_user'@'%';<br>GRANT SELECT ON inventory.* TO 'report_user'@'%';
另外，mysql 系统库默认禁止普通用户访问（即使显式授权也会被服务端拦截），information_schema 和 performance_schema 的权限控制逻辑也不同于普通库，不要试图用库级权限绕过这些限制。
