mysqldump默认需select、lock tables、show view、trigger权限，缺一即报错退出；使用--single-transaction可省lock tables但需replication client；导出事件还需event权限；权限授予须用反引号包裹库名、限定主机、执行flush privileges。
只给 SELECT 权限是跑不通 mysqldump 的，缺了 LOCK TABLES、SHOW VIEW 或 TRIGGER 中任意一个，dump 就会直接报错退出。
mysqldump 默认行为到底要哪些权限
它不是只读数据那么简单——默认会尝试锁表、查视图定义、导出触发器、访问元数据。不满足就中断，不会跳过或静默忽略。
-
SELECT：必须，否则连第一行数据都读不出来 -
LOCK TABLES：默认启用（非--single-transaction模式下），MyISAM 表没它直接报Access denied; you need (at least one of) the LOCK TABLES privilege(s) -
SHOW VIEW：库中只要有一个视图，没这权限就会报错并跳过该视图，甚至整个 dump 失败 -
TRIGGER：mysqldump默认开启--triggers，带触发器的表若无此权限，生成的 SQL 缺失CREATE TRIGGER语句
用 --single-transaction 时能省掉 LOCK TABLES 吗
可以，但有条件：仅限 InnoDB 表 + MySQL ≥5.7.21，且你得额外加 REPLICATION CLIENT 权限。
-
--single-transaction依赖 MVCC 快照，确实不需要LOCK TABLES - 但它内部会执行
SELECT @@global.gtid_mode和SHOW MASTER STATUS，缺REPLICATION CLIENT会报Access denied; you need (at least one of) the REPLICATION CLIENT privilege(s) - 如果备份还含事件（
EVENT），得单独加EVENT权限；否则事件不会被导出
GRANT 语句怎么写才不出错
常见翻车点不是权限漏了，而是语法或范围写错了——比如库名含短横、主机没限定、忘了 FLUSH PRIVILEGES。
- 数据库名必须用反引号包裹：
GRANT SELECT ON `my-app`.* TO 'backup_user'@'localhost';（否则解析失败） - 主机限定越严越好：
'backup_user'@'10.0.2.5'比'backup_user'@'%'安全得多 - 别写
GRANT ALL PRIVILEGES ON *.*——这等于给了DROP DATABASE、SHUTDOWN等高危能力 - 执行完必须
FLUSH PRIVILEGES;，尤其在跳过 grant 表启动或权限表被手动修改后，否则权限不生效
密码和配置文件的安全盲区
权限配再细，密码明文塞命令行或配置文件权限宽松，等于白干。
- 禁用
mysqldump -u backup_user -p...这种命令行传密，改用--defaults-extra-file=/etc/mysql/backup.cnf - 该配置文件必须属主为 backup 用户、权限为
600：chmod 600 /etc/mysql/backup.cnf - 内容只保留
[client]段，且仅含user和password，不写host或port（防连错实例） - 别用
mysql_config_editor存密——生成的~/.mylogin.cnf同样要chmod 600，否则等同于泄露密码
最易被忽略的是跨库引用：哪怕只授权了 app_db.*，如果里面某个视图定义里 SELECT FROM log_db.audit_log，mysqldump 仍会因无法访问 log_db 而失败——这时候得显式补上 log_db 的 SELECT 权限。
