phpMyAdmin UI不支持通配符表名授权，因其权限界面仅接受真实存在的数据库名，不解析SQL通配符或自动转义下划线；必须通过SQL执行GRANT语句，如GRANT SELECT ON myapp.myapp\_% TO 'appuser'@'localhost'，并确保库存在、用户匹配、执行FLUSH PRIVILEGES。
phpmyadmin 的 ui 不支持通配符表名授权，必须用 sql 手动执行 grant 语句才能生效。
为什么在 phpMyAdmin 权限页面填 myapp\_% 没用
你点开「用户账户」→「编辑权限」→在数据库下拉选「使用文本字段」并输入 myapp\_% 或 `myapp\_%`，这个操作看似合理，但底层不会生成合法的 GRANT 语句。phpMyAdmin 的权限编辑界面只接受真实存在的数据库名，它把表级通配逻辑完全屏蔽了——UI 层根本不解析 SQL 风格的通配符，也不会自动转义下划线 _。
真正起作用的只有 MySQL 原生语法，且必须满足几个硬性前提：
-
GRANT中的数据库名（如`myapp`）必须是已创建的真实库 - 表名模式（如
`myapp\_%`）里的_必须用反斜杠转义，否则会被当成“任意单字符”匹配 - 不能用
ALL PRIVILEGES，否则会隐式要求mysql系统库权限，大概率报错Access denied; you need (at least one of) the SUPER privilege(s)
怎么用 SQL 正确授予前缀表权限
打开 phpMyAdmin 的「SQL」标签页，用有 GRANT OPTION 的账号（如 root）执行：
GRANT SELECT, INSERT, UPDATE ON `myapp`.`myapp\_%` TO 'appuser'@'localhost';
注意这几点：
立即学习“PHP免费学习笔记（深入）”；
- 数据库名
`myapp`和用户名主机部分'appuser'@'localhost'必须和实际连接时完全一致（'appuser'@'%'≠'appuser'@'localhost'） - 如果前缀是
log_，就写`log\_%`；如果是cache_，就写`cache\_%` - 执行完必须立刻运行
FLUSH PRIVILEGES;，否则内存缓存不更新，权限不会生效 - 如果该用户之前已有更宽泛的权限（比如整个
myapp库的SELECT），新授的窄权限不会覆盖旧权限，得先REVOKE再GRANT
通配符权限生效后容易被忽略的隐患
这种授权方式最大的问题不是“设不设得成”，而是“设完之后没人盯得住”。MySQL 会自动把权限应用到所有符合前缀的新建表上，比如你后来加了 myapp_notifications、myapp_metrics，用户无需额外操作就能读写。
这意味着：
- 没人审核新表是否该被该用户访问——开发提 PR 加表，DBA 可能根本不知道权限已扩散
- 权限回收只能靠
REVOKE整体撤销，无法按表粒度精细控制 - 如果某张前缀表里存了敏感字段（比如
myapp_users里有password_hash），而用户只需要查日志表，那就存在越权风险
所以，除非业务明确需要动态扩展且信任所有前缀表结构，否则更稳妥的做法是：明确列出每张表，用标准的数据库+表级权限分配，哪怕多点操作，也比失控强。
