Hyperf报“权限不足”90%源于CURRENT_USER()与预期不一致或连接池复用导致权限失效；需执行SELECT USER(), CURRENT_USER()确认真实登录用户，检查mysql.user表中host精确匹配，并用SHOW GRANTS FOR CURRENT_USER()验证生效权限，同时配置pool.max_idle_time

Hyperf 应用连 MySQL 报“权限不足”，90% 不是账号没授权，而是 CURRENT_USER() 和你预期的不一致，或者连接池配置让权限在协程上下文中失效了。

查清你真正连的是哪个用户

别信命令行里写的 -u app，MySQL 认证时只看 CURRENT_USER() 返回值。在 Hyperf 里执行一条原始查询：

SELECT USER(), CURRENT_USER();

如果返回类似 'app'@'127.0.0.1' 和 'app'@'localhost'，说明你从 TCP 连（127.0.0.1）却只给 'app'@'localhost' 授了权——这两个 host 完全不等价，权限不会复用。

• 用 SELECT Host, User FROM mysql.user WHERE User = 'app'; 看所有匹配账号
• 用 SHOW GRANTS FOR CURRENT_USER(); 查当前 session 真实生效的权限（不是建库脚本，不是记忆）
• Hyperf 默认走 TCP，除非显式配置 unix_socket；若应用部署在容器或远程服务器，host 必须写成 IP 段或 %，不能只留 localhost

GRANT 后权限不生效的三个高频原因

在 Hyperf 中执行 GRANT SELECT ON mydb.* TO 'app'@'10.0.2.%'; 却仍报错，大概率卡在这三点：

Hyperframes Creative

HyperFrames视频非动画创意指导，包括设计规范（frame.md/design.md）处理、配色、字体设计、旁白及节奏规划等。

下载

• FLUSH PRIVILEGES; 没执行——虽然 MySQL 5.7+ 多数情况自动刷新，但 Hyperf 长连接池可能缓存旧权限状态，保险起见必须手动刷
• host 字段大小写敏感或含不可见空格：'app'@'% ' 和 'app'@'%' 是两个用户，查 mysql.user 表时用 SELECT TRIM(Host) FROM mysql.user WHERE User='app';
• 权限层级冲突：比如全局给了 USAGE，又在库级给了 SELECT，但中间某条 DENY（MySQL 8.0+）覆盖了它；用 SHOW GRANTS FOR CURRENT_USER(); 能看到最终合并结果

Hyperf 连接池导致“权限突然失效”的配置坑

Hyperf 的连接池会复用连接，如果 MySQL 服务端因超时主动断开（wait_timeout），而连接池没及时探测并剔除，下次取出的连接就处于“已认证但权限丢失”状态，表现就是随机报权限错误。

• 确认 MySQL 的 wait_timeout 值：SHOW VARIABLES LIKE 'wait_timeout';（通常默认 28800 秒，但某些云厂商改得极短，如 60 秒）
• 把 Hyperf 的 pool.max_idle_time 设为比它小至少 30 秒（例如 MySQL 是 60，则设 max_idle_time: 30.0）
• 启用有效心跳：pool.heartbeat: 15.0（必须 ≤ max_idle_time），且确保驱动支持 PING；否则 fallback 到 checker: 'SELECT 1'，但该语句不能在事务中执行
• 不要设 min_connections: 0，冷启动时新建连接若遇到权限问题，整个 Worker 就卡住

CREATE DATABASE 权限在 Hyperf 里特别难授？

不是难授，是你大概率授错了对象。Hyperf 应用本身不需要 CREATE 全局权限——那等于允许它删库跑路。正确做法是：

• 用 root 或高权限账号提前建好库：CREATE DATABASE app_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• 再授最小权限：GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER ON app_db.* TO 'app'@'10.0.2.%';
• 如果真需要运行时建库（如多租户场景），必须授 CREATE + GRANT OPTION，但 GRANT OPTION 会让该用户能再转授权限，风险极高
• Hyperf 的 migration 命令（php bin/hyperf.php migrate）执行时也走同一连接池，所以建表失败往往也是因为 CURRENT_USER() 权限不够，而非 migration 配置问题

最易被忽略的一点：Hyperf 的协程连接池里，每个连接是独立认证的。如果你在代码里用 DB::connection('other')->select(...) 切了连接名，就得单独确认那个连接配置对应的用户是否拥有对应权限——不是“一个账号通吃所有 connection”。