LOCK TABLES权限需显式授予且必须执行FLUSH PRIVILEGES才生效，因该权限独立于SELECT等权限；授予后仍失败常见原因包括未刷新权限、用户host不匹配、或混用MyISAM表导致强制锁表需求。
为什么备份时提示“LOCK TABLES command denied”
执行 mysqldump 或 phpmyadmin 内置导出时出现 lock tables command denied to user，本质是当前 mysql 账户缺少 lock tables 权限。这个权限不是默认赋予的，即使有 select 和 show view 也不够——它独立控制表级锁操作，用于保证备份一致性。
在 phpMyAdmin 界面中直接授予权限的步骤
phpMyAdmin 自带的权限管理界面能完成授权，但必须用具备 GRANT OPTION 的高权限账号（如 root）登录：
- 左侧选择对应数据库 → 点击顶部「权限」标签页
- 点击「添加用户账户」或找到已有用户 → 点击「编辑权限」
- 滚动到「全局权限」或「数据库特定权限」区域（取决于你希望授权范围）
- 勾选
LOCK TABLES，同时确保已勾选SELECT、SHOW VIEW、TRIGGER（若含触发器） - 务必点击「刷新权限」（或页面底部的「Go」），否则变更不生效
命令行方式更可靠，避免 phpMyAdmin 缓存干扰
有时 phpMyAdmin 界面操作后权限未即时同步，推荐用 SQL 直接执行：
GRANT LOCK TABLES ON `your_database_name`.* TO 'your_username'@'localhost';
注意替换 your_database_name 和 your_username；如果用户是从远程连接，把 localhost 换成对应 host（如 % 或具体 IP）；执行后必须运行：
FLUSH PRIVILEGES;
否则 MySQL 不会加载新权限。漏掉这步是常见失败原因。
立即学习“PHP免费学习笔记（深入）”；
备份时仍失败？检查是否启用了 --single-transaction
如果使用 mysqldump 并加了 --single-transaction 参数，InnoDB 表其实不需要 LOCK TABLES——它靠 MVCC 实现一致性快照。此时报错往往是因为 dump 同时处理 MyISAM 表或视图，而这些引擎强制要求锁表。解决办法：
- 确认库中是否混用 MyISAM 表：
SELECT ENGINE, COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' GROUP BY ENGINE; - 若存在 MyISAM，要么转换为 InnoDB，要么保留
LOCK TABLES权限 - 导出时显式排除非 InnoDB 表，或改用
--lock-tables（而非--single-transaction）
权限本身很简单，但实际生效依赖 GRANT 执行、FLUSH、存储引擎行为三者配合——少一个环节，备份就卡在锁表那步。
