SELECT权限不够用是因为mysqldump默认需LOCK TABLES和RELOAD权限保证备份一致性；最小权限组合为SELECT+LOCK TABLES+RELOAD，按库精确授权，禁用SHOW DATABASES和.通配，避免%主机，GRANT后无需FLUSH PRIVILEGES。
创建只读用户时为什么 SELECT 权限不够用？
因为 MySQL 备份（尤其是 mysqldump）默认需要 LOCK TABLES 和 RELOAD 权限来保证一致性，否则会报错：Access denied; you need (at least one of) the LOCK TABLES privilege(s) for this operation。但这些权限本身不等于“可写”，只要不给 INSERT/UPDATE/DELETE/DROP 等权限，仍是安全的只读镜像账户。
实操建议：
- 最小权限组合是：
SELECT+LOCK TABLES+RELOAD（RELOAD用于FLUSH TABLES WITH READ LOCK，mysqldump --single-transaction可绕过它，但非事务表仍需） - 如果只备份 InnoDB 表且明确加
--single-transaction，可省略LOCK TABLES和RELOAD，仅留SELECT - 千万别给
SHOW DATABASES—— 否则用户能列出所有库名，暴露结构信息
GRANT 语句里指定库名和不指定的区别在哪？
不指定库（如 GRANT SELECT ON *.*）会让用户看到所有库名（触发 SHOW DATABASES 隐式权限），且一旦新增库就自动获得访问权，不符合“镜像指定库”的初衷。
实操建议：
- 按实际备份范围精确授权，例如只备份
app_db：GRANT SELECT, LOCK TABLES, RELOAD ON app_db.* TO 'backup_user'@'192.168.1.%' - 若需跨多个库备份，逐个授权，不要用
*.*：GRANT SELECT ON billing_db.* TO 'backup_user'@'...'; GRANT SELECT ON user_db.* TO 'backup_user'@'...'; - 主机地址尽量限制 CIDR 段，避免用
'%'（尤其公网环境）
执行 FLUSH PRIVILEGES 是不是每次都要？
不用。只有通过直接操作 mysql.user 等系统表改权限时才需要；用 GRANT 语句授权后，权限立即生效，FLUSH PRIVILEGES 不但多余，还可能掩盖语法错误（比如误写成 GRAN，执行完才发现没生效）。
常见错误现象：
- 执行
GRANT后立刻用新用户连接失败 → 检查是否漏了IDENTIFIED BY或密码策略不匹配（MySQL 8.0+ 默认caching_sha2_password） - 权限看起来给了，但
mysqldump仍报错 → 实际是没给LOCK TABLES，或用户从错误 host 连入（backup_user@'localhost'和backup_user@'127.0.0.1'是两个不同账户）
MySQL 8.0 的角色（ROLE）能简化只读用户管理吗？
能，但要注意兼容性。角色适合批量管理多个只读用户，比如统一定义 role_backup_reader，再把权限赋予角色，最后把角色授给用户。不过旧版客户端或某些备份工具（如 Percona XtraBackup 早期版本）可能不识别角色上下文，导致权限不生效。
实操建议：
- MySQL 5.7 及以下：别用角色，老老实实用
GRANT - MySQL 8.0+ 且确认工具链支持：先建角色：
CREATE ROLE role_backup_reader;，再授权：GRANT SELECT, LOCK TABLES, RELOAD ON app_db.* TO role_backup_reader;，最后绑定：GRANT role_backup_reader TO 'backup_user'@'%'; - 角色必须显式激活才能生效：
SET DEFAULT ROLE role_backup_reader TO 'backup_user'@'%';，否则新用户登录后权限为空
最容易被忽略的是：备份用户必须能连上 MySQL，但很多运维只配了权限，忘了开防火墙、检查 bind_address 是否监听了对应网卡，或者 SELinux 拦截了 socket 连接。权限对了，连都连不上，就全白搭。
