LOCK TABLES权限属于全局权限，只能通过ON .授予，不可按库或表指定；若授予权限后仍报错，需检查host匹配、连接重连及角色是否生效。
LOCK TABLES 权限属于全局权限，不能按库或表授予
MySQL 的 LOCK TABLES 权限无法像 SELECT 那样指定到 db_name.table_name，它只在全局层级（*.*）有效。试图写成 GRANT LOCK TABLES ON mydb.* TO 'user'@'%' 会报错 ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES。
原因在于：锁表操作影响服务器线程状态和并发控制，MySQL 要求该权限必须由具备全局视角的账户持有，避免局部授权引发死锁或元数据不一致。
-
LOCK TABLES必须搭配ON *.*使用，例如：GRANT LOCK TABLES ON *.* TO 'backup_user'@'10.0.2.%' - 若用户已拥有
SELECT等库级权限，仅追加LOCK TABLES不会自动获得其他管理权，但需注意——它常与FLUSH TABLES配合使用，而后者也属全局权限 - MySQL 8.0+ 中，即使通过角色授予
LOCK TABLES，角色本身仍需在全局层级被赋予，不能绑定到某库
为什么 mysqldump 备份失败，却提示 “LOCK TABLES denied”
这不是权限漏配，而是工具默认行为与权限作用域不匹配。mysqldump 在加 --single-transaction 时可跳过锁表，但若显式传了 --lock-tables 或未指定事务选项，就会尝试执行 LOCK TABLES 语句——此时哪怕用户对目标表有完整 SELECT 权限，没有 LOCK TABLES ON *.* 仍会报 ERROR 1045 (28000): Access denied for user ... using password: YES 或更具体的 ERROR 1044 (42000): Access denied for user ... to database ''（空库名暴露了全局权限缺失）。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 检查 mysqldump 命令是否含
--lock-tables、--master-data或--flush-logs—— 这些都会触发锁表逻辑 - 生产备份推荐用
--single-transaction --skip-lock-tables组合，依赖 InnoDB MVCC，无需LOCK TABLES - 若必须锁表（如 MyISAM 表），则确认用户权限语句中明确写了
ON *.*，且没被REVOKE ALL PRIVILEGES ON *.*意外清空
授完 LOCK TABLES 权限后还是被拒绝？三个关键检查点
权限生效不等于能立刻执行锁表，中间存在三处典型断点：
- 用户 host 匹配失败：授权的是
'backup'@'10.0.2.%'，但连接串里用的是backup@10.0.2.15—— 看似匹配，实际 MySQL 会优先匹配最精确的host记录；查SELECT user, host FROM mysql.user WHERE user = 'backup';确认是否存在更优先的'backup'@'10.0.2.15'行且没授权限 - 旧连接未重连：权限变更对已建立连接无效，必须让客户端断开重连，或管理员执行
KILL CONNECTION <id></id>强制刷新 - 被角色覆盖：MySQL 8.0+ 用户可能通过角色间接获得权限，但角色若被
REVOKE或DROP ROLE，会导致权限突然消失；运行SHOW GRANTS FOR 'user'@'host';看输出里是否真含LOCK TABLES，而非仅显示ROLE = 'xxx'
最小化风险：不要给应用账号 LOCK TABLES
这个权限本质是运维向的，不是业务向的。一旦开放，用户就能阻塞其他会话的 DML，甚至配合 FLUSH TABLES WITH READ LOCK 造成全库只读——这在高并发场景下极易引发雪崩。
- Web 应用、API 服务账号一律禁止授予
LOCK TABLES；只读账号更只需SELECT，完全不需要它 - 备份专用账号可授，但应限制 host 为备份服务器 IP 段，并搭配
ACCOUNT LOCK平时禁用：ALTER USER 'backup'@'10.0.2.%' ACCOUNT LOCK; - 真正需要锁表的场景极少，多数可通过事务隔离级别、
SELECT ... FOR UPDATE或应用层分布式锁替代
最容易被忽略的是：LOCK TABLES 和 UNLOCK TABLES 必须在同一连接内成对出现，跨连接释放会失败，且锁不会自动超时——这意味着一个忘写 UNLOCK 的脚本，可能让整张表卡住数小时。
