设置Multi-Statements处理模式

使用场景

当通过数据库代理执行Multi-Statements时，可以根据业务场景选择不同的处理模式。

模式描述

• Strict模式（默认）：该模式下，Multi-Statements会发往主节点，当前连接的后续请求读写分离失效，会全部路由到主节点，需断开当前连接并重新连接才能恢复读写分离。该模式不会解析Multi-Statements，性能好，适合短连接、无连接复用场景。
• Loose模式：该模式下，Multi-Statements会发往主节点，当前连接的后续请求依旧可以读写分离。该模式不会解析Multi-Statements，性能好，适合Multi-Statements内仅含DML SQL，不含设置session变量、创建临时表、创建存储过程、执行未提交事务等操作的场景。
• Parse模式：该模式下，只读Multi-Statements会根据权重路由，读写混合Multi-Statements会发往主节点，同时数据库代理会解析Multi-Statements，根据Multi-Statements内包含的SQL情况（具体见Parse模式场景说明），决定当前连接的后续请求是否恢复读写分离，由于该模式会解析Multi-Statements，对代理性能有一定影响，影响程度与Multi-Statements的长度和复杂性相关，建议Multi-Statements小于100MB，避免数据库代理解析SQL消耗过多的资源，引起性能明显下降。

Parse模式场景说明

当Multi-Statements包含如下场景时，后续请求会全部路由到主节点，需断开当前连接并重新连接才能恢复读写分离。

• Multi-Statements内创建临时表。
• Multi-Statements内创建存储过程。
• Multi-Statements内含未提交的事务（如执行了begin，但未commit或rollback）。
• Multi-Statements过于复杂或含特殊语法等导致Multi-Statements解析失败。

更改Multi-Statements模式立即生效，无需重启数据库代理。但如果模式切换前存在因为执行了Multi-Statements导致读写分离失效的连接，不会因为切换模式而恢复读写分离，需要断开重连才能恢复。