mysql如何实现读写分离的权限分配_不同用户分别赋予权限

读用户仅授SELECT权限，写用户授SELECT/INSERT/UPDATE/DELETE，禁用系统库权限，REPLICATION SLAVE仅用于从库同步，权限变更需重连生效，跨库查询须显式授权。只给读用户 SELECT 权限，别碰 INSERT/UPDATE/DELETE读写分离的前提是「人不能越权」，MySQL 本身不自动区分读写流量，靠的是应用连接不同账号——读账号连从库，写账号连主库。所以权限必须从账号粒度切开。常见错误是给读用户加了 USAGE 或漏掉 GRANT OPTION 导致后续无法授权，或者误授 SHOW VIEW、LOCK TABLES 等隐式写权限。读用户只执行：GRANT SELECT ON mydb.* TO 'reader'@'%'; FLUSH PRIVILEGES;写用户才需要：GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'writer'@'%';禁止对系统库（mysql、information_schema）授任何权限，哪怕只读如果用视图，SELECT 权限不够——还需 SHOW VIEW，但这是潜在风险点，慎开REPLICATION SLAVE 权限不是给应用用户的，是给从库同步用的有人看到从库要同步，就顺手给应用账号加 REPLICATION SLAVE，这是典型混淆角色。这个权限只用于从库 I/O 线程拉取 binlog，和应用读写完全无关，且一旦拥有，就能获取主库所有 binlog 内容，属于高危权限。真正该检查的是：从库上是否已禁用应用账号登录（比如绑定 skip-networking 或防火墙限制），否则读用户可能直连从库后执行非预期操作。主库上无需给 reader 或 writer 授 REPLICATION SLAVE从库上建议用独立账号（如 repl）专管复制，且仅允许来自主库 IP应用账号在从库上只保留 SELECT，且最好限定 host 为应用服务器段，而非 '%'权限变更后，FLUSH PRIVILEGES 不一定立刻生效MySQL 8.0+ 默认启用缓存，权限变更后，已建立的连接仍沿用旧权限，直到重连。这不是 bug，是设计——为了性能不每次都查权限表。 Julius AI Julius AI是一款功能强大的AI数据分析工具，可以快速分析和可视化复杂数据。