最可靠方式是执行show grants for 'app_user'@'10.20.30.%';查看真实权限，再核对grant option、super等高危项，并确认主机名与应用连接完全一致。
直接在 phpMyAdmin 里做权限审计，不是点几下“导出”就能完事的——它不自动标记高危配置、不提示权限冲突、也不校验主机名匹配是否合理。真要审出问题，得靠组合动作：查当前权限 + 对比最小需求 + 验证连接行为。
怎么看一个用户实际拥有哪些权限
phpMyAdmin 的「Edit privileges」页面只显示界面勾选项，但真实权限可能来自多层叠加（全局 + DB级 + 表级 + 角色），甚至被 REVOKE 显式屏蔽过。最可靠的方式是用 SQL 查：
- 在「SQL」标签页执行
SHOW GRANTS FOR 'app_user'@'10.20.30.%';，看输出是否含GRANT OPTION、SUPER、FILE等危险权限 - 若用户属于角色，还要查
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'app_user' AND TO_HOST = '10.20.30.%';（MySQL 8.0+） - 注意：界面里没显示「Global privileges」区域，不代表没全局权限——可能是你登录账号没
GRANT OPTION，导致 phpMyAdmin 压根不渲染该区块
哪些权限组合算“明显越权”
审计时盯住三类信号，它们大概率意味着权限失控：
-
GRANT OPTION出现在应用账号上：它不可回收，且允许该用户再授予权限，等于埋下权限扩散炸弹 -
SUPER、SHUTDOWN、FILE、PROCESS出现在非 DBA 账号里：这些不是“查数据”，而是“关数据库”“读服务器文件”“杀线程” - 同一用户有
'app_user'@'localhost'和'app_user'@'127.0.0.1'两套权限：MySQL 8.4 默认开启 DNS 解析，二者完全独立，容易漏审一条，导致应用连不上却查不出原因
怎么验证权限改对了，而不是“看起来像对了”
改完权限后别只信界面反馈——phpMyAdmin 不验证连接串是否带 dbname=，也不检查 USE db_name 是否被执行。常见失效场景：
- 只在「Database-specific privileges」里授权
app_db，但没清空「Global privileges」里的USAGE或残留勾选：用户仍能看到其他库名（只是进不去），PDO 初始化时可能抛Unknown database - 应用连接字符串没指定数据库，代码里又没写
USE app_db：首次查询会失败，报错却是Access denied for user，让人误判为权限问题 - 测试时用 phpMyAdmin 自带连接测试，但该测试默认走
localhost，而应用实际从10.20.30.5连——主机名不匹配，权限根本没生效
真正安全的审计，是把「权限语句」、「连接方式」、「应用行为」三者对齐；最容易被跳过的，是确认应用连接时用的 host 和 username 是否和你审计的那条记录完全一致——少一个点、多一个空格、IP 和域名混用，都可能导致权限形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
