MySQL 8.0+中LOCK TABLES是库级权限，必须显式授予ON db_name.，不能用ON .*；否则mysqldump --single-transaction在fallback时因缺权限报错。
直接给备份账号授予 SELECT 和 LOCK TABLES 权限即可，但必须注意：这两个权限不能跨库授予通配符（如 myapp_%），也不能只授给 *.* 就完事——MySQL 8.0+ 要求 LOCK TABLES 必须按具体库名显式授予，否则 mysqldump --single-transaction 会 fallback 到锁表逻辑并报错。
为什么 GRANT SELECT, LOCK TABLES ON *.* 在 MySQL 8.0+ 会失败
MySQL 8.0 开始，LOCK TABLES 不再是全局权限，它被降级为「数据库级权限」。这意味着：
-
GRANT ... ON *.*语法虽然能执行成功，但实际不会把LOCK TABLES授予任何库 -
mysqldump在启用--single-transaction时，若发现事务隔离无法完全规避一致性风险（比如含 MyISAM 表、或某些 DDL 操作中），会自动尝试FLUSH TABLES WITH READ LOCK或逐表LOCK TABLES ... READ—— 此时就要求用户在对应库上有LOCK TABLES权限 - 结果就是报错：
Access denied; you need (at least one of) the LOCK TABLES privilege(s) for this operation
正确创建最小权限备份账号的 SQL 语句
假设你要备份的库名为 myapp_db，且运行环境是 MySQL 8.0+（2026 年主流版本）：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_password_2026'; GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `myapp_db`.* TO 'backup_user'@'localhost'; FLUSH PRIVILEGES;
说明：
-
SHOW VIEW和TRIGGER是可选但强烈建议加上的——否则导出视图或触发器会失败，mysqldump默认会尝试导出它们 - 库名用反引号包裹（
`myapp_db`），避免库名含特殊字符或关键字时报错 - 如果要备份多个库（如
myapp_db和log_db），必须分别执行两次GRANT，不能写成ON `myapp_db`.*, `log_db`.*—— MySQL 不支持这种多库语法
验证权限是否真的生效
别信 GRANT 执行成功就完事。登录后手动测试最可靠：
mysql -u backup_user -p -e "SELECT COUNT(*) FROM myapp_db.users;" mysql -u backup_user -p -e "LOCK TABLES myapp_db.users READ;"
常见失败点：
- 第二条命令报错？说明
LOCK TABLES没授对，检查是否漏了库名或用了*.* - 第一条查不到数据？先确认库名大小写（Linux 下区分大小写），再检查是否误授给了其他库名（比如拼错成
myappdb） - 用
SHOW GRANTS FOR 'backup_user'@'localhost';查看实际授予的权限，注意输出里必须出现类似GRANT SELECT, LOCK TABLES ON `myapp_db`.*的行
备份脚本里怎么用才不踩坑
在 shell 脚本中调用 mysqldump 时，优先使用 --single-transaction，但它不是万能的：
- 对 InnoDB 表有效，能避免锁表；但遇到 MyISAM、MEMORY 表或含
SELECT ... FOR UPDATE的长事务，仍会触发LOCK TABLES - 务必加
--routines --triggers --events（如果需要导出存储过程/事件），否则即使权限给了TRIGGER和EVENT，mysqldump默认也不导 - 不要在脚本里硬编码密码；用
~/.my.cnf存凭证，并设chmod 600 ~/.my.cnf，内容示例：
[client] user=backup_user password=strong_password_2026
真正容易被忽略的是：权限配置完成之后，没验证 LOCK TABLES 是否能在目标库上实际执行 —— 很多故障都是备份时突然卡住或报错才发现，而不是部署前。
