MySQL 8.0+中LOCK TABLES是数据库级权限，必须显式授予ON db_name.，不能用ON .*，否则mysqldump --single-transaction fallback时因缺权限报错。
直接给备份账号 SELECT 和 LOCK TABLES 权限是基础，但 MySQL 8.0+ 下必须按库显式授予，否则 mysqldump --single-transaction fallback 时会报错。
为什么 GRANT SELECT, LOCK TABLES ON *.* 在 MySQL 8.0+ 不生效
MySQL 8.0 把 LOCK TABLES 降级为数据库级权限，ON *.* 语法虽能执行成功，但实际不会赋予任何库的该权限。当 mysqldump 启用 --single-transaction 却遇到 MyISAM 表或 DDL 并发时，会 fallback 到逐库 LOCK TABLES READ，此时因缺权限直接失败：
Access denied; you need (at least one of) the LOCK TABLES privilege(s) for this operation
这不是 mysqldump 的 bug，而是权限模型变更后的必然行为。
正确授予权限的 SQL 写法（MySQL 8.0+）
假设你要备份 app_db 和 log_db 两个库：
- 数据库名必须用反引号包裹：
`app_db`，否则库名含短横（如my-app）或数字开头会报语法错误 - 不能合并写成
ON `app_db`.*, `log_db`.*—— MySQL 不支持多库通配符授权，必须分条执行 -
REPLICATION CLIENT只在需要--master-data或记录 binlog 位点时才加，且可跨库授予：ON *.* -
SHOW VIEW和TRIGGER强烈建议加上，否则视图和触发器导出失败，dump 可能中断
完整语句示例：
CREATE USER 'backup_user'@'10.0.2.5' IDENTIFIED BY 'strong_password_2026';<br>GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `app_db`.* TO 'backup_user'@'10.0.2.5';<br>GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `log_db`.* TO 'backup_user'@'10.0.2.5';<br>GRANT REPLICATION CLIENT ON *.* TO 'backup_user'@'10.0.2.5';<br>FLUSH PRIVILEGES;
容易被忽略的三个实操坑
权限配对了，但脚本仍失败，大概率栽在这三点：
- 主机地址写成
'backup_user'@'%'：生产环境必须限定具体 IP（如'backup_user'@'10.0.2.5'），%是最大安全隐患 - 密码明文出现在
mysqldump -u backup_user -p命令行里：应改用--defaults-extra-file=/etc/mysql/backup.cnf，且该文件权限必须是600、属主为 backup 用户 - 执行完
GRANT忘了FLUSH PRIVILEGES：尤其在跳过 grant 表启动或手动修改过权限表时，权限不生效
最麻烦的不是权限漏了哪个，而是库名没加反引号、主机没锁死、配置文件权限开太大——这些细节一错，整个备份流程就卡在第一行。
