单独撤销 LOCK TABLES 无效，因其依赖 ALTER 权限；需同步撤销 LOCK TABLES 和 ALTER，精准匹配 host，执行 FLUSH PRIVILEGES，并通过新连接行为验证。
直接执行 REVOKE LOCK TABLES ON *.* FROM 'user'@'host' 无法真正禁用——因为该权限依赖 ALTER 才能生效，且在 phpMyAdmin 等界面中不单独显示，必须同步清理两处并验证连接状态。
为什么单独撤销 LOCK TABLES 总是失败
MySQL 实际校验 LOCK TABLES 时，会连带检查用户是否拥有 ALTER 权限。即使你只保留 LOCK TABLES 而撤掉 ALTER，执行 LOCK TABLES t READ 仍会报错 ERROR 1045 (28000): Access denied。这不是 bug，而是 MySQL 的隐式依赖逻辑。
更麻烦的是：LOCK TABLES 在 phpMyAdmin 5.1+ 中被归入「结构」权限组，不会作为独立选项出现；你手动勾选/取消「结构」权限时，界面可能已悄悄联动了 ALTER、DROP、LOCK TABLES 三者，但你无法确认哪一项真正起效。
- 它不是列级或表级权限，只能在数据库级（
db_name.*）或全局级（*.*）撤销 - 它不走角色继承链的常规路径——如果用户通过角色获得
ALTER，那LOCK TABLES就自动可用，但SHOW GRANTS不会显示LOCK TABLES -
USAGE权限不影响它，但已建立的连接会缓存旧组合，导致撤销后仍能锁表
正确回收步骤：SQL 直接操作 + host 精准匹配
绕过界面模糊性，用 SQL 显式撤销最可靠。注意：必须覆盖所有可能的 Host 值，'u'@'localhost' 和 'u'@'%' 是两个完全独立账号。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先查用户实际有哪些 host 记录：
SELECT Host, User FROM mysql.user WHERE User = 'u'; - 对每个 host 分别执行（以
myapp库为例）：REVOKE LOCK TABLES, ALTER ON myapp.* FROM 'u'@'localhost'; - 若用户有全局
ALTER（如GRANT ALTER ON *.* TO 'u'@'%'），必须补上：REVOKE LOCK TABLES, ALTER ON *.* FROM 'u'@'%'; - 执行
FLUSH PRIVILEGES;—— 这次不能省，因为LOCK TABLES的权限缓存刷新不自动触发
验证是否真生效：别信 SHOW GRANTS
SHOW GRANTS FOR 'u'@'localhost' 可能仍显示 LOCK TABLES，哪怕你刚撤销过——这是 MySQL 缓存和权限表读取顺序导致的假象。真实验证必须靠行为测试。
- 用该用户新开一个命令行或 phpMyAdmin 标签页（确保是新连接）
- 执行：
LOCK TABLES orders READ; - 预期结果是
ERROR 1227 (42000): Access denied; you need (at least one of) the LOCK TABLES privilege(s) for this operation或ERROR 1045 - 如果成功锁住，说明漏掉了某个 host，或该用户绑定了含
ALTER的角色，需查mysql.role_edges
最容易被忽略的残留点
回收完别急着收工。真正的风险藏在三个地方：一是用户通过角色间接持有 ALTER（查 SELECT FROM_HOST, FROM_USER FROM mysql.role_edges WHERE TO_USER = 'u'）；二是备份账号（如 mysqlbackup）常被赋予 LOCK TABLES 用于一致性备份，这类账号容易被当成“非管理员”漏处理；三是活跃连接未断开，旧 session 仍可执行 UNLOCK TABLES 后再次锁表——必须 KILL 掉对应连接或等应用重启连接池。
