phpMyAdmin不控制表结构修改权限，真正起作用的是MySQL用户是否拥有ALTER权限；禁用需在MySQL层面显式移除ALTER等权限，而非依赖phpMyAdmin界面操作。
phpMyAdmin 本身不控制表结构修改权限，靠 MySQL 权限体系限制
phpmyadmin 只是前端界面，它不会主动“禁止”或“允许”alter table——真正起作用的是你登录所用的 mysql 用户是否拥有 alter 权限。如果你看到某用户在 phpmyadmin 里点不了“结构”页的“更改”按钮，或点击后报错 error 1142 (42000): alter command denied，那说明该账号没被授予对应权限。
常见错误现象：管理员以为在 phpMyAdmin 的“用户账户”里取消勾选“结构”相关权限就能禁用改表，结果发现没用——因为 phpMyAdmin 的权限界面只影响它自己渲染哪些菜单项，**不实际撤销 MySQL 底层权限**。
- 必须用 MySQL 原生命令或 phpMyAdmin 的“用户账户”→“编辑权限”→“全局权限”页，显式移除
ALTER、CREATE、DROP、INDEX这几项 - 如果只针对某张表（比如
wp_users），要在“数据库特定权限”里选中对应库 → 点“更改权限” → 取消勾选该表的ALTER - 注意：MySQL 8.0+ 的角色（role）机制可复用权限集，但 phpMyAdmin 对角色支持有限，建议直接赋权给用户
为什么禁用 ALTER 后，“结构”页仍能打开甚至显示“编辑”图标？
这是 phpMyAdmin 的 UI 行为惯性——它会加载表结构元数据（靠 SELECT 权限），并默认渲染所有字段操作入口。但当你点击“编辑”或“保存”时，后端执行的仍是 ALTER TABLE，此时 MySQL 才真正拦截并返回权限错误。
所以不能依赖界面是否灰掉来判断权限是否生效，必须实测：ALTER TABLE test_table MODIFY COLUMN id INT 是否报错。
- phpMyAdmin 不会在“结构”页做前置权限检查，这是设计使然，也是它轻量的原因
- 某些旧版本（如 4.x）甚至会把“添加字段”按钮一直显示，直到提交时才失败
- 若需彻底隐藏 UI 入口，只能改 phpMyAdmin 源码（不推荐）或用 Web 层拦截（如 Nginx 返回 403 到
tbl_structure.php）
生产环境最稳妥的禁用方式：最小权限 + 账号隔离
别指望单靠一个账号开关搞定。真实场景下，应分层控制：
立即学习“PHP免费学习笔记（深入）”；
- 应用账号（如 WordPress 连接用的
wp_user）：只给SELECT、INSERT、UPDATE、DELETE，**绝对不给ALTER或CREATE** - 运维账号（如
dba_admin）：保留完整权限，但仅限内网 IP 或跳板机访问，并配合$cfg['AllowDeny']在 config.inc.php 中白名单限制 - 临时调试账号：用
CREATE USER ... WITH MAX_QUERIES_PER_HOUR 0限流，或设account_locked = 'Y'（MySQL 5.7.6+）快速启停
权限一旦设置，FLUSH PRIVILEGES 并非总是必需——MySQL 8.0 默认动态加载，5.7 多数情况也不需要，除非你直接改了 mysql.user 表。
绕过权限检查的常见漏洞点
即使禁了 ALTER，以下路径仍可能被利用，必须同步堵住：
-
setup/目录未删除：历史上多个 RCE 漏洞由此触发，直接rm -rf setup/ -
themes/目录可写：攻击者上传含 PHP 逻辑的主题，通过主题加载机制执行任意代码 - Web 服务器错误配置：允许
.php文件在import.php上传后被执行（哪怕只是临时目录） - phpMyAdmin 配置文件
config.inc.php可写：攻击者注入恶意$cfg设置，如关闭认证或开启 debug
真正禁用表结构修改，不是关掉一个按钮，而是让 ALTER 命令在 MySQL 层根本走不通，且任何能间接触发它的通道都被物理阻断——权限、目录权限、Web 规则、PHP 运行时缺一不可。
