不能。只读副本仅支持select查询，dml操作必须在主副本执行，因其数据库处于restoring状态，底层恢复机制禁止任何写入，read_write_routing_url仅实现连接重定向而非写分流。
不能。只读副本无法分担 DML 读写压力。 DML（INSERT、UPDATE、DELETE）必须在主副本上执行，只读副本仅支持 SELECT 类查询，且默认拒绝任何写操作请求。
为什么只读副本不接受 DML 请求
SQL Server Always On 可用性组中，次要副本的数据库处于 RESTORING 状态，由日志流持续重做（redo）维持同步。该状态天然禁止用户发起任何修改操作——这是底层恢复机制决定的，不是配置可绕过的限制。
常见错误现象包括：
- 连接成功但执行
UPDATE时抛出错误：The target database, 'xxx', is in an availability group and is currently configured for read-only access. - 即使将
SECONDARY_ROLE (ALLOW CONNECTIONS = ALL)，DML 仍失败，仅SELECT成功
READ_WRITE_ROUTING_URL 不是“读写分离”，而是“自动重定向”
READ_WRITE_ROUTING_URL 是 SQL Server 2019 引入的连接路由能力，但它不改变副本角色权限，只解决客户端连错副本时的容错问题。
它的实际作用是：
- 当客户端连接字符串指向一个次要副本，且
ApplicationIntent=ReadWrite（或未指定，默认值），SQL Server 会主动把连接重定向到当前主副本 - 重定向发生在登录阶段，不经过应用层，对客户端透明
- 它依赖主副本已配置
PRIMARY_ROLE (READ_WRITE_ROUTING_URL)，且次要副本处于联机状态
注意：这和“把部分写请求发给只读副本”完全无关，只是避免因连接字符串硬编码了旧主库地址导致故障转移后连接失败。
真正能缓解读写压力的路径只有两条
若业务面临高并发 DML 压力，只读副本本身无解，需转向以下方向：
-
主库自身优化：检查阻塞链、索引缺失、参数化不足、统计信息陈旧；启用内存授予反馈（
MEMORY_GRANT_FEEDBACK）减少并行溢出 -
架构级分流：将非核心 DML 拆出，例如日志类
INSERT写入独立归档库，或使用 Service Broker 异步化写入 -
读写分离 ≠ 写分离：所有写仍集中于主副本，只读副本只能分担
SELECT压力；若读压力不大而写压力突出，加只读副本毫无帮助
最容易被忽略的一点是：很多人误以为配置了 READ_ONLY_ROUTING_LIST 就等于实现了“读写分离”，其实它只影响 ApplicationIntent=ReadOnly 的连接路由；而 DML 请求压根不会走到这一步——它们要么被重定向，要么直接报错。真正的写扩展，得靠分库、分表、或者迁移到支持多写拓扑的系统（如 SQL Server 的对等复制，但生产环境极少用）。
