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” 的告警。
