17370845950

SQL只读库的有效隔离需权限控制、连接约束、监控拦截和应用加固四者协同：权限层面严格限制DML/DDL操作；连接层配置read_only参数并限制高危连接选项；监控层实时审计非SELECT语句并告警；应用侧分离读写连接池、启用readonly事务属性并做流量回放测试。

SQL只读库的核心目标不是“完全杜绝写操作”，而是通过多层机制让写入变得困难、可感知、可拦截——真正有效的隔离，靠的是权限控制 + 连接约束 + 监控兜底，三者缺一不可。

权限层面：从源头掐断写能力

数据库用户权限必须严格按最小原则分配。只读账号不应拥有 INSERT、UPDATE、DELETE、DROP、TRUNCATE、ALTER、CREATE 等任何 DML 或 DDL 权限，连 SELECT INTO（可能隐式建表）和 EXECUTE（调用含写逻辑的存储过程）也要谨慎授权。

• PostgreSQL：使用 REVOKE ALL ON DATABASE ... 后，再显式 GRANT SELECT ON TABLES IN SCHEMA ...
• MySQL：创建用户时指定 GRANT SELECT ON db.* TO 'ro_user'@'%'; FLUSH PRIVILEGES;，避免用 GRANT USAGE 模糊授权
• SQL Server：将用户加入 db_datareader 角色，并确认未在 db_owner、db_datawriter 中

连接层面：强制只读会话行为

即使权限受限，某些数据库仍允许客户端在连接时声明 SET SESSION TRANSACTION READ ONLY 或启用 read_only=ON 全局参数——但这只是“软限制”，不能替代权限控制，仅作为第二道防线。

• MySQL：在只读实例上配置 read_only=ON（主库需设为 read_only=OFF），并确保复制线程有 SUPER 权限绕过该限制
• PostgreSQL：设置 default_transaction_read_only = on，配合 pg_hba.conf 对只读用户限定 hostssl ... ro_user ... md5，避免本地 superuser 绕过
• 注意：应用连接字符串中若含 allowMultiQueries=true 或 autoReconnect=true，可能意外触发写语句重试，需同步检查

监控与拦截：让异常写操作无处遁形

权限和连接配置可能被绕过（如高权限账号误用、应用配置错误、SQL 注入），因此必须部署实时审计和告警。

• 开启数据库原生审计日志（如 MySQL 的 general_log 或企业版 Audit Log；PG 的 log_statement = 'mod'）
• 用 SQL 解析工具（如 pt-query-digest、pgBadger）过滤出非 SELECT 语句，对 ro_user 发起的写操作立即短信/钉钉告警
• 在代理层（如 ProxySQL、ShardingSphere-Proxy）配置规则：匹配用户+关键字（INSERT/UPDATE/…），直接拒绝并记录上下文

应用侧加固：别把锅全甩给DBA

很多“误写”其实源于应用层未区分读写数据源，或 ORM 自动拼写 INSERT ... ON DUPLICATE KEY UPDATE 等隐式写语句。

• 在应用配置中明确分离读写连接池，只读池只连只读库地址，且连接 URL 加 ?readOnly=true&failOverReadOnly=true（JDBC）
• MyBatis / Hibernate 等框架启用 readonly=true 事务属性，或自定义拦截器校验 SQL 类型
• 上线前做 SQL 流量回放测试，用只读账号跑一遍核心链路，捕获所有非法写请求

不复杂但容易忽略：真正的只读隔离，是权限卡死、连接设防、日志盯梢、应用守门四件事一起做，少一个环节，就可能在凌晨三点收到一条 “UPDATE t_user SET balance = -999999 WHERE id = 123” 的告警。