热升级 2.0 在实例小版本升级时，通过共享存储的副本实例和平滑流量切换，显著降低升级过程对业务的可见影响。相比传统热升级，该方案能够将升级期间的查询失败、连接中断等问题控制在更小范围内。本文为您介绍热升级 2.0 的使用限制和升级影响。
使用限制
在使用热升级 2.0 前，请确认您的实例满足以下条件。
实例类型与版本
仅支持计算组实例（Warehouse）。
实例需先升级至 V4.0 及以上大版本的最新小版本。满足条件的实例可以在控制台的自助升级功能中选择热升级 2.0。自助升级的操作步骤，请参见实例升级。
升级范围
仅支持小版本升级，暂不支持大版本升级。
不支持的特性与操作
升级过程中，以下特性或操作无法做到完全无损，可能出现失败或连接断开，请提前在业务侧做好规避或重试准备。
DDL 约有 1~3 分钟的失败窗口。
多行 DML 和 DQL 事务会失败，即通过
hg_experimental_enable_transaction显式开启的事务。通过
CREATE TEMP TABLE创建的会话级临时表，相关读写会失败。单条查询的执行时间超过 1 小时会失败。
Fixed FE 连接，即通过
jdbc_fixed模式建立的连接，在升级时会断开。通过非
jdbc_fixed模式消费 Binlog 的连接，在升级时会断开。
升级影响
在满足使用限制的前提下，热升级 2.0 对业务的典型影响如下。
查询
普通 DQL 查询不会失败。
受 Cache 失效和查询重试影响，部分查询可能出现短暂抖动。
写入
普通 DML 写入不会失败。
切换期间新写入会有短暂重试，整体写入延迟增加约 1~3 分钟。
DDL
副本角色切换期间，DDL 有约 1~3 分钟的失败窗口，客户端重试后一般可恢复。
连接
升级期间，空闲连接会断开一次，需要客户端重连。
除使用限制中列出的特性外，其余连接可以在升级过程中保持。
升级时长
升级总时长取决于实例上长查询的结束时间。系统会等待老实例上没有活跃查询后再下线老实例，因此正在执行的长查询会延长整体升级时间。