mysqldump默认需select、lock tables、show view、trigger权限，缺一即报错退出；使用--single-transaction可省lock tables但需replication client；导出事件还需event权限；权限授予须用反引号包裹库名、限定主机、执行flush privileges。
mysqldump 默认需要哪些权限才不报错
只给 SELECT 权限，mysqldump 会直接退出，不是卡住或跳过——它会在遇到第一个视图、触发器或 MyISAM 表时就报错。必须配齐以下几项才能跑通默认行为：
-
SELECT：读取所有表数据（必需） -
LOCK TABLES：用于非事务引擎或--single-transactionfallback 场景（必需） -
SHOW VIEW：否则含视图的库 dump 失败或静默跳过（强烈建议） -
TRIGGER：否则导出的 SQL 缺失CREATE TRIGGER（默认开启--triggers）
漏掉任意一个，错误信息都可能模糊，比如 Access denied; you need (at least one of) the LOCK TABLES privilege(s) 或 Cannot load table structure for view xxx，实际原因未必是字面提示的那个。
MySQL 8.0+ 中 LOCK TABLES 权限不能 ON *.*
在 MySQL 8.0+ 上执行 GRANT SELECT, LOCK TABLES ON *.* TO 'backup_user'@'localhost' 看似成功，但 LOCK TABLES 实际没生效——因为该权限已被降级为数据库级，ON *.* 不会绑定到任何具体库。结果就是 mysqldump --single-transaction 在碰到 MyISAM 表或长事务时 fallback 到锁表逻辑，然后报权限拒绝。
- 必须显式写成
GRANT SELECT, LOCK TABLES ON `myapp_db`.* TO 'backup_user'@'localhost' - 库名要用反引号包裹，尤其当库名含短横、数字开头或关键字时（如
`my-app-v2`） - 要备份多个库，得逐个授权：
GRANT SELECT, LOCK TABLES ON `log_db`.* TO ...，不能合并写 -
REPLICATION CLIENT可以跨库授（ON *.*），因为它仍是全局权限
用 --single-transaction 能省掉 LOCK TABLES 吗
可以，但有条件限制，且会引入新依赖：
- 仅对 InnoDB 表有效；MyISAM 表仍强制走锁表路径，缺
LOCK TABLES就失败 - MySQL 版本需 ≥ 5.7.21（2026 年主流环境基本满足）
- 必须额外加
REPLICATION CLIENT权限——mysqldump内部会执行SHOW MASTER STATUS和SELECT @@global.gtid_mode，缺它会报Access denied; you need (at least one of) the REPLICATION CLIENT privilege(s) -
--single-transaction不解决视图和触发器问题，SHOW VIEW和TRIGGER仍要保留
所以“省掉 LOCK TABLES”不是删权限，而是换一组更窄但更特定的依赖。
权限配完还连不上？检查这三处硬伤
权限语句执行成功 ≠ 备份能跑通。常见卡点不在 SQL 本身，而在外围配置：
- 主机限定太松或太紧：
'backup_user'@'%'允许任意 IP 连接，不安全；'backup_user'@'localhost'在容器或远程备份时可能因 socket/IP 解析失败而连不上，应按实际部署写死 IP（如'backup_user'@'10.0.2.5'） - 密码传入方式不安全：
mysqldump -u backup_user -p会把密码暴露在进程列表里；必须改用--defaults-extra-file=/etc/mysql/backup.cnf，且该文件权限必须是600、属主为运行备份的用户 -
FLUSH PRIVILEGES没执行：虽然多数情况下 GRANT 后立即生效，但在跳过 grant 表启动、或手动修改过mysql.user表后，不执行就真不生效
最易被忽略的是：权限对已存在的连接无效。如果应用或备份脚本维持着长连接，改完权限后得重启连接池或等待重连，否则还是旧权限。
