phpMyAdmin 5.1+ 中 LOCK TABLES 权限不独立显示，而是与 ALTER 打包在「结构」权限组中，仅在数据库特定权限折叠区有条件出现；撤销时必须同步取消 LOCK TABLES 和 ALTER 权限，并执行 FLUSH PRIVILEGES。
phpMyAdmin 5.1+ 界面里根本找不到 LOCK TABLES 权限选项
这不是你漏看了，是它被隐藏了。LOCK TABLES 不作为独立权限项出现在「全局权限」或「表级权限」列表中，而是和 ALTER、DROP 等一起打包进「结构」权限组，且只在「数据库特定权限」的折叠区域里有条件显示。你切换到「用户账户」→「编辑权限」→「数据库」标签页，找到目标库点「编辑权限」，才可能看到那个勾选框——前提是该用户此前没被授予过全局 ALTER。
撤销 LOCK TABLES 必须同时取消 ALTER 权限
MySQL 内部校验时，LOCK TABLES 实际依赖 ALTER 权限。即使你在界面上只勾掉 LOCK TABLES 而保留 ALTER，执行 LOCK TABLES t READ 仍会报错：ERROR 1045 (28000): Access denied。所以必须同步操作：
- 进入目标数据库的「编辑权限」页，在「结构」组里取消勾选
LOCK TABLES和ALTER - 如果用户有全局
ALTER ON *.*（比如通过GRANT ALTER ON *.* TO 'u'@'%'），还得回到「全局权限」标签页单独取消 - host 匹配必须全覆盖：
'u'@'localhost'和'u'@'%'是两个完全独立的账号，少清一个就白忙
用 SQL 撤销最可靠，且必须加 FLUSH PRIVILEGES
图形界面容易漏掉权限来源（比如通配库 * 或不同 host），直接执行 SQL 更明确：
REVOKE LOCK TABLES, ALTER ON `your_db`.* FROM 'u'@'%'; FLUSH PRIVILEGES;
注意两点：
-
your_db要替换成实际库名；若想全库禁用，写成*.* -
FLUSH PRIVILEGES不可省——MySQL 5.7+ 对多数权限自动生效，但 LOCK TABLES 这类旧权限项不刷新缓存，不执行就无效
验证是否真生效，别信界面显示
SHOW GRANTS 输出可能残留旧记录，连接也未必立即重载。真实验证方式是：
- 用该用户新开一个 phpMyAdmin 标签页（或命令行重新连接）
- 执行
LOCK TABLES some_table READ - 预期结果是
ERROR 1045或ERROR 1227；若成功锁住，说明某处ALTER或LOCK TABLES还挂着
最容易被忽略的是 host 细节和连接未断开导致的权限缓存延迟——操作完务必换新连接测试，不能只看界面勾选状态。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
