最安全的从库同步账号配置是仅授予REPLICATION SLAVE权限、限定具体IP（如'repl'@'192.168.10.22'）、强密码且禁用密码过期，不赋SELECT等额外权限，配合防火墙最小放行及TLS加密。
复制账号必须只给 REPLICATION SLAVE 权限
复制账号不是业务账号，它唯一作用是让从库连接主库并读取 binlog。给它 SELECT、ALL PRIVILEGES 或 RELOAD 都是多余且危险的——这些权限一旦泄露或误用，可能被用于数据导出、锁表甚至服务中断。
MySQL 5.7+ 只需一条授权语句：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.5.20'。注意：ON *.* 是语法要求，不代表开放所有库表操作权限，这只是 MySQL 复制协议规定的固定写法，实际只用于拉取 binlog 事件。
- 不要加
WITH GRANT OPTION：复制账号绝不能转授权限 - 不要混用
REPLICATION CLIENT：除非你用 GTID 模式且需要监控脚本调用SHOW MASTER STATUS，否则纯复制链路不需要它 - MySQL 8.0+ 中，
REPLICATION SLAVE自动隐含部分元数据读取能力，无需额外补SELECT或SHOW DATABASES
主机名必须精确匹配从库真实 IP
写成 'repl'@'%' 看似方便，但在生产环境等于把 binlog 访问权暴露给整个网络。更糟的是，MySQL 8.0 默认使用 caching_sha2_password 插件时，'%' 无法匹配该认证方式，导致从库连不上，报错 ERROR 1045 (28000) 或静默失败。
- 查从库真实出口 IP：
hostname -I或ip route get 1.1.1.1 | awk '{print $7}' - 授权时用 CIDR 更稳妥（K8s 场景）：
'repl'@'10.100.0.0/255.255.0.0' - 避免
'repl'@'localhost'：这是主库本地环回地址，从库根本连不进来
MySQL 8.0+ 创建复制账号常卡在 ERROR 3092
这不是权限没给够，而是密码策略拦截了。MySQL 8.0 默认 default_password_lifetime = 360，只要账号密码“年龄”超期，REPLICATION SLAVE 权限就会被静默禁用，执行 CHANGE MASTER TO 时直接报 ERROR 3092 (HY000)。
- 建号时显式禁用过期：
CREATE USER 'repl'@'192.168.5.20' IDENTIFIED BY 'p' PASSWORD EXPIRE NEVER - 别用
SET GLOBAL default_password_lifetime = 0：这会全局弱化所有账号安全，不推荐 - 检查现有账号是否已过期：
SELECT user, host, password_expired FROM mysql.user WHERE user = 'repl'
FLUSH PRIVILEGES 到底要不要执行？
绝大多数情况下不用。但复制账号是个例外：如果你是直接修改系统表（比如用 UPDATE mysql.user 手动改 host 或密码），或者 MySQL 启动时加了 --skip-grant-tables 参数，那必须手动 FLUSH PRIVILEGES 才能让内存权限缓存生效。
- 正常走
CREATE USER+GRANT流程，权限立即生效，FLUSH PRIVILEGES是冗余操作 - 但很多旧文档和自动化脚本仍保留这句，执行也无害，建议保留以防跳过 grant 表启动等边缘情况
- 执行后验证：
SHOW GRANTS FOR 'repl'@'192.168.5.20'必须看到REPLICATION SLAVE出现在结果里
权限最小化最难的部分不是语法，而是坚持每次新增从库都重新算一遍 IP 段、重走一遍建号流程——没人愿意为“又一台从库”再开一次工单审批，但跳过这步，复制账号就从最小权限退化成了最大攻击面。
