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数据分析工具可以快速分析和可视化复杂数据。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2594893.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!