phpMyAdmin无法直接撤销表权限，必须手动执行REVOKE语句；需先用SHOW GRANTS确认显式授权，再执行REVOKE SELECT ON db.table FROM 'user'@'host'并FLUSH PRIVILEGES。
phpMyAdmin 里没法直接“撤销表权限”
phpmyadmin 只是 mysql 的图形界面，它本身不管理权限，所有权限操作最终都落到 mysql 的 grant 和 revoke 语句上。你点“用户账户”→“编辑权限”，看到的只是当前用户的全局/数据库级权限快照，**没有“表级权限编辑器”**——这点很多人误以为能点几下就搞定。
常见错误现象：
• 在用户权限页勾掉某个数据库的 SELECT，但该用户仍能查某张表（因为之前单独给过这张表 GRANT SELECT ON db.t1）
• 点了“刷新权限”，但表级权限没变（FLUSH PRIVILEGES 不影响已存在的表级授权记录）
- 必须用 SQL 手动执行
REVOKE，不能依赖 phpMyAdmin 的 UI 操作 - 先确认目标用户对哪张表有显式授权：查
mysql.tables_priv表，或运行SHOW GRANTS FOR 'user'@'host' - phpMyAdmin 默认禁用对
mysql系统库的写操作，所以无法直接在它的 SQL 标签页删tables_priv记录——得用命令行或允许系统库访问的管理员账号
撤销单张表的 SELECT 权限（以 user@localhost 为例）
这是最常遇到的场景：开发账号能连库，但不该碰 users 表。关键不是“去掉数据库权限”，而是精准收回那张表的授权。
操作前务必确认两点：
• 用户是否真的有这张表的显式授权（SHOW GRANTS FOR 'user'@'localhost' 输出里有没有 ON `mydb`.`users`）
• 用户是否还通过角色（MySQL 8.0+）间接获得权限（角色权限需单独 REVOKE）
- 执行
REVOKE SELECT ON mydb.users FROM 'user'@'localhost'; - 必须跟
FLUSH PRIVILEGES;（MySQL 5.7 及以前必需；8.0+ 在多数情况下自动重载，但显式执行更稳） - 注意引号：数据库名、表名若含特殊字符或大小写敏感，要用反引号
`包裹，比如REVOKE INSERT ON `prod-db`.`order_log` - 撤销后立即生效，无需重启服务，但客户端可能缓存权限（可让应用重连验证）
撤销权限后用户还能访问表？检查这三处
撤销完发现用户照样能查，大概率掉进这三个坑：
立即学习“PHP免费学习笔记（深入）”；
- 用户有更高优先级的权限：比如同时有
SELECT ON mydb.*（库级）和SELECT ON mydb.users（表级），只撤表级无效——MySQL 权限是叠加的，库级权限覆盖表级限制 - 用户属于某个角色，而角色有该表权限：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'user'@'localhost';查关联角色，再对角色执行REVOKE SELECT ON mydb.users FROM 'role_name'@'%'; - 使用了通配符主机名（如
'user'@'%'），但你撤销的是'user'@'localhost'——这两个是不同账号，权限互不影响
phpMyAdmin 中执行 REVOKE 的实操限制
即使你有管理员账号，在 phpMyAdmin 的 SQL 标签页执行 REVOKE 也可能失败，原因很实际：
- 默认配置禁止非超级用户执行权限语句：检查 phpMyAdmin 配置里的
$cfg['Servers'][$i]['DisableIS']和allow_user_drop_database，但更关键的是 MySQL 层的super_priv或system_user权限 - phpMyAdmin 的“用户账户”页只能增删改数据库级权限，表级权限字段（
Table_priv）压根不显示，也没提供输入框 - 安全起见，生产环境建议用 MySQL 命令行或专用 DBA 工具操作，避免 phpMyAdmin 因超时、编码、SQL 模式等问题截断或误解析
REVOKE语句
真正要细粒度控权，就得直面 MySQL 权限模型本身——表级权限不是开关，是独立授权记录，撤销动作不可逆，且不会自动清理冗余路径。留心那些被 GRANT 过多次的账号，它们的权限状态往往比看起来复杂得多。
