直接授予 LOCK TABLES 权限而未同步授予对应表的 SELECT 权限会导致执行 LOCK TABLES t1 READ 时报错 ERROR 1095；该权限仅支持库级或全局粒度，不支持单表授权，且必须配合 FLUSH PRIVILEGES 生效。
直接给用户加 LOCK TABLES 权限会出什么问题
LOCK TABLES 不是独立权限项，它依赖于全局 LOCK TABLES 权限（MySQL 8.0+ 中叫 LOCK_TABLES_ADMIN），但更关键的是：它**必须配合 SELECT 权限一起生效**。如果只授 LOCK TABLES 而没给对应表的 SELECT，执行 LOCK TABLES t1 READ 会报错 ERROR 1095 (HY000): You are not allowed to execute this command。
常见误操作包括：
- 在 MyWebSQL 界面勾选
Lock tables却没同步检查该用户是否已有对应库表的SELECT权限 - 用
GRANT LOCK TABLES ON *.*授予全局锁权，结果用户能锁mysql系统表，引发运维事故 - 授予
LOCK TABLES后忘记FLUSH PRIVILEGES，尤其在 MySQL 5.7 或启用了skip-grant-tables的环境下
怎么安全地授予某张表的 LOCK TABLES 权限
MySQL 不支持“只对某张表授予 LOCK TABLES”，这个权限粒度只到数据库级（db_name.*）或全局（*.*）。但你可以通过组合控制来实现逻辑上的“表级锁定”：
- 先创建专用临时用户：
CREATE USER 'lock_report'@'192.168.1.%' IDENTIFIED BY 'lock@2026'; - 只授权目标库下的表读取 + 锁定：
GRANT SELECT, LOCK TABLES ON report_db.* TO 'lock_report'@'192.168.1.%'; - 禁止越权：不授
INSERT/UPDATE/DELETE，也不授WITH GRANT OPTION - 执行
FLUSH PRIVILEGES;（跨版本兼容性保障）
验证方式：用该用户登录后执行 LOCK TABLES orders READ;，成功即表示权限就绪；若失败，优先查 SHOW GRANTS FOR 'lock_report'@'192.168.1.%'; 确认输出中是否含 LOCK TABLES 和对应库名。
为什么 MyWebSQL 勾了 Lock tables 还是锁不了表
MyWebSQL 的「Lock tables」开关只是设置 LOCK TABLES 全局权限位，它不校验底层权限依赖。你可能遇到这些真实情况：
- 用户主机段不匹配：MyWebSQL 里选的是
'user'@'%'，但实际连接用的是'user'@'192.168.1.100'，权限记录未命中 - MySQL 8.0+ 默认禁用事件调度器，而某些 MyWebSQL 插件依赖它做权限同步（少见但存在）
- 用户被
ACCOUNT LOCK或PASSWORD EXPIRE卡住，连都连不上，自然无法锁表 - 使用了 ProxySQL 或 DB 中间件，权限缓存未刷新，导致界面显示已授权、实际无效
排查顺序建议：SELECT User, Host, account_locked, password_expired FROM mysql.user WHERE User = 'xxx'; → SHOW GRANTS FOR 'xxx'@'yyy'; → 用相同 host 段直连 MySQL 命令行复现。
临时锁定需求更适合用 FLUSH TABLES WITH READ LOCK 吗
不是替代关系，是不同场景。如果你要的是「让整个库只读、阻止所有写入」，那 FLUSH TABLES WITH READ LOCK 更彻底，但它需要 BACKUP_ADMIN 或 SUPER 权限（MySQL 8.0+），普通用户根本拿不到——所以给业务用户开 LOCK TABLES 是唯一可行路径。
但要注意：LOCK TABLES 是会话级的，断开连接自动释放；而 FLUSH TABLES WITH READ LOCK 是全局阻塞，必须配对执行 UNLOCK TABLES，否则整个库卡死。临时权限场景下，前者可控，后者危险。
真正容易被忽略的是：LOCK TABLES 的 READ 锁不能防止其他会话用 INSERT DELAYED 或 REPLACE 绕过，如需强一致性备份，请直接走 mysqldump --single-transaction 或物理快照，别依赖锁表。
