应为用户分配最小必要权限：按库授予select/insert/update/delete，限定具体ip段而非'%'，禁用create/drop等高危权限，分离主从与应用账号，结合网络层控制。
如何用 GRANT 为用户分配最小必要读写权限
直接给 SELECT、INSERT、UPDATE、DELETE 四个权限，比给 ALL PRIVILEGES 安全得多，也更符合实际业务需求。
常见错误是把权限赋给 'user'@'%' 却忘了只允许从特定网段连入，结果暴露在公网；或者用 GRANT ... ON *.* 给了跨库权限，而应用其实只操作一个库。
- 按库授权：用
GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.* TO 'app_user'@'192.168.10.%' - 避免通配符主机：不用
'app_user'@'%'，改用具体 IP 段或内网 DNS 名（如'app_user'@'web-server-01'） - 执行后必须跟
FLUSH PRIVILEGES（仅在直接修改mysql.user表时才需要；用GRANT通常自动生效）
为什么不能跳过 CREATE 和 DROP 权限就认为“只读”安全
表面看只给了 SELECT 就是只读，但若用户还能创建临时表、视图或函数，就可能绕过限制——比如用 CREATE VIEW 包装敏感字段，再通过 SELECT 间接读取；或用 CREATE TEMPORARY TABLE 缓存并重写数据逻辑。
真正只读场景下，应显式拒绝高危操作：
- 不授予
CREATE、DROP、ALTER、INDEX、CREATE VIEW、SHOW VIEW - 检查是否残留旧权限：
SHOW GRANTS FOR 'report_user'@'localhost' - 若用 MySQL 8.0+，可考虑角色（
CREATE ROLE）统一管理只读策略，避免逐个用户重复配置
REPLICATION SLAVE 权限不是给应用用户的，而是给从库同步用的
很多团队误把主从同步账号当成普通应用账号复用，导致应用意外具备读取 binlog 的能力，存在数据泄露和被注入风险。
正确做法是严格分离账号用途：
- 主从复制专用账号：只赋予
REPLICATION SLAVE+REPLICATION CLIENT，主机限定为从库 IP - 应用读写账号：仅限业务库的 DML 权限，禁止任何 replication 相关权限
- 监控账号（如 Prometheus）：只需
PROCESS、REPLICATION CLIENT、SELECTonperformance_schema，不碰业务表
MySQL 8.0 的 password_history 和 password_reuse_interval 对权限管控的实际影响
权限本身不控制密码策略，但弱密码会让已有权限的账号更容易被爆破或冒用。MySQL 8.0 内置的密码历史机制能降低凭证复用风险，属于权限体系的必要补足。
配置示例（在 mysql.user 表或 CREATE USER 时设置）：
CREATE USER 'app_user'@'192.168.10.%' IDENTIFIED WITH 'caching_sha2_password' BY 'StrongPass!2024' PASSWORD HISTORY 5 PASSWORD REUSE INTERVAL 365 DAY;
注意：PASSWORD HISTORY 只对后续改密生效，不会追溯已存在的旧密码；且只有使用 caching_sha2_password 或 sha256_password 插件才支持该策略。
权限设计最易忽略的点，是没把网络层访问控制（如防火墙、VPC 安全组）和数据库层权限做联动——哪怕 SQL 权限收得再严，如果端口对全网开放，一切都没意义。
