更新时间:2024-09-06 GMT+08:00
分享

设置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,但未commitrollback)。
  • Multi-Statements过于复杂或含特殊语法等导致Multi-Statements解析失败。

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

相关文档