华为云用户手册

请求参数 表2 请求Header参数 参数 是否必选 参数类型 描述 X-Auth-Token 是 String 参数解释： 用户Token。 通过调用 IAM 服务获取用户Token接口获取（响应消息头中X-Subject-Token的值）。 约束限制： 必传。 取值范围： 字符串长度不少于1，不超过10万。 默认取值： 不涉及。 表3 请求Body参数 参数 是否必选 参数类型 描述 params 是 MindmapPageParam object 脑图分页查询参数 表4 MindmapPageParam 参数 是否必选 参数类型 描述 offset 否 Integer 参数解释： 起始偏移量，表示从此偏移量开始查询，offset大于等于0，小于等于100000 limit 否 Integer 参数解释： 每页显示的条目数量，最大支持200条 name 否 String 参数解释： 脑图名称 取值范围： 大小写字母、数字、符号、中文。 长度限制1-500位 长度限制1-500位 id_collection 否 Array of strings ID集合 folder_id_collection 否 Array of strings 目录ID集合 project_id 是 String 参数解释： 项目ID 取值范围： 大小写字母、数字。 长度限制固定32位 folder_root_id 否 String 参数解释： 所属目录的根目录ID 取值范围： 1.-1：特性目录其他目录 2.requirement_root_id：需求根目录 3.feature_root_id：特性根目录 branch_uri 否 String 参数解释： 分支uri 取值范围： 大小写字母、数字。 长度限制1-34位 iterator_uri 否 String 参数解释： 计划uri 取值范围： 大小写字母、数字。 长度限制0-34位 is_master 否 Integer 参数解释： 是否基线 取值范围： 0，表示非基线。 1，表示是基线。 creator_name_collection 否 Array of strings 创建者名称集合 updater_name_collection 否 Array of strings 更新人名称集合

响应示例 状态码：200 OK { "code" : "success", "data" : null, "message" : null } 状态码：400 Bad Request { "error_code" : "TESTMIND.00021882", "error_msg" : "分支、计划id长度不合法，请稍后重试" } 状态码：401 Unauthorized { "error_code" : "DEV.00000003", "error_msg" : "认证信息过期" }

响应参数 状态码：200 表3 响应Body参数 参数 参数类型 描述 code String 参数解释： 接口调用错误码 data String 接口调用返回体 message String 参数解释： 接口调用错误信息 状态码：400 表4 响应Body参数 参数 参数类型 描述 code String 参数解释： 接口调用错误码 data String 接口调用返回体 message String 参数解释： 接口调用错误信息 状态码：401 表5 响应Body参数 参数 参数类型 描述 code String 参数解释： 接口调用错误码 data String 接口调用返回体 message String 参数解释： 接口调用错误信息

使用须知 开启或关闭SSL会导致实例重启，请谨慎操作。 开启SSL后，可以通过SSL方式连接数据库，具有更高的安全性。 出于安全原因，不安全的加密算法已被禁用。GeminiDB Mongo支持的安全加密算法对应的加密套件如表1所示。 表1 安全加密算法对应的加密套件说明 版本 支持的TLS版本 支持的加密算法套件 4.0 TLS 1.2 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 用户的客户端所在服务器需要支持对应的TLS版本以及对应的加密算法套件，否则会连接失败。 关闭SSL，可以采用非SSL方式连接数据库。

操作场景 SSL（Secure Socket Layer，安全套接层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。 认证用户和服务器，确保数据发送到正确的客户端和服务器。 加密数据以防止数据中途被窃取。 维护数据的完整性，确保数据在传输过程中不被改变。 SSL连接开启后，可以通过SSL方式连接实例，提高数据安全性。

解决方案 修改Migration实时集成作业配置。 Migration任务中必须关闭异步compaction动作，同时将clean和archive关闭。具体来说，可以在“Hudi表属性全局配置”或单表的“表属性编辑”中配置下表所示参数。 表1 Hudi表参数 参数名 参数值 含义 compaction.schedule.enabled true 开启compaction计划生成 compaction.delta_commits 60 compaction计划生成的compaction次数触发周期 compaction.async.enabled false 关闭异步compaction clean.async.enabled false 清理历史版本数据文件 hoodie.archive.automatic false Hudi commit文件老化的开关 图1 关闭Migration compaction任务 如上配置项配置完成后，作业启动后不再进行compaction任务，只会定期生成compaction计划，Spark SQL作业可以通过“run compaction on”命令执行compaction计划。 compaction计划一定需要Migration任务生成，然后交给Spark执行，否则会有Hudi Timeline的冲突，导致Spark compaction作业执行失败。 创建Spark SQL周期性Compaction任务。 前往 DataArts Studio 数据开发界面，参考《开发批处理单任务SQL作业》创建Spark SQL作业。 图2 创建Spark SQL单任务作业 配置与Hudi相对应的Spark数据连接，并选中需要操作Hudi表对应的数据库。 图3 配置连接与数据库 根据实际情况配置compaction的调度周期。 图4 配置调度周期 Hudi数据表Compaction规范 参考Hudi数据表Compaction规范填写Spark SQL的compaction语句，提交并运行作业。 图5 提交并运行作业

参数说明及使用 与session中的参数类似，在NDP中我们提供了两种表级（table-level hint）的开关，分别是： NDP_PUSHDOWN NO_NDP_PUSHDOWN 其中，NDP_PUSHDOWN为启用NDP，NO_NDP_PUSHDOWN为关闭NDP。进行此参数设置时需要指定表。使用方法如下： SELECT /*+ NO_NDP_PUSHDOWN(t) */ * FROM t; // 表t不执行NDP SELECT /*+ NO_NDP_PUSHDOWN(t, u) */ * FROM t, u; // 表t和u不执行NDP SELECT /*+ NDP_PUSHDOWN(t1) */ * FROM t as t1; //表t1执行NDP SELECT /*+ NDP_PUSHDOWN(t) */ * FROM t; // 表t执行NDP SELECT /*+ NDP_PUSHDOWN(t1, u1) */ * FROM t as t1, u as u1; //表t1和u1执行NDP SELECT /*+ NDP_PUSHDOWN() */ * FROM t as t1, u as u1; //()语法表示为查询块中的所有表启用NDP。

主节点与只读节点的通信 虽然主节点与只读节点共享底层存储数据，但是主节点和只读节点之间仍需要进行信息通信。 主节点发送到只读节点内容：redo的描述信息，比如redo日志的最新lsn和内部读取日志的接口信息。 只读节点发送到主节点内容： 只读节点当前的视图，视图中保存了当前的事务列表，主节点根据各个节点的视图信息，才能对undo日志进行purge清理。 只读节点的recycle_lsn，recycle_lsn表示只读节点读取数据页的最小lsn。对于只读节点来说，读取的数据页的lsn不会小于recycle lsn，主节点收集各个只读节点的recycle_lsn，来评估清理底层redo日志的位点。 各个只读节点的基本信息如节点ID, 最新消息更新时间戳等，用来主节点对只读节点的管理。 进行通信后，只读节点才能读取redo日志，进行数据可见性的更新，即从存储侧读取redo日志并推进全局数据可见的lsn（visible lsn）。

只读延迟的计算 只读延迟是指在主节点更新数据后，在多少时间后能在只读节点得到这个最新数据。 只读节点读取redo日志进行缓存数据更新，对应的redo日志的lsn，称为visible lsn，表示只读节点能读取数据页的最大lsn。对于主节点来说，每更新或者插入一条数据产生的最新redo日志的lsn为flush_to_disk_lsn，表示主节点能访问的数据页的最大lsn。只读延迟其实就是只读节点visible lsn相比于主节点flush_to_disk_lsn的延迟，举个例子，比如t1时刻：主节点flush_to_disk_lsn=100， 只读节点visible lsn=80, 经过一段时间只读节点回放redo日志后，t2时刻：主节点 flush_to_disk_lsn=130，只读节点visible lsn=100。那么此时我们可以计算出只读延迟为：t2-t1，因为经过t2-t1的时间后只读节点才能读取主节点t1时刻的数据。

只读节点visible lsn的推进 根据延迟的计算方式，产生延迟的关键点在于只读节点visible lsn推进速度的快慢。 只读节点推进visible lsn的工作流程如下： 只读节点通过与主节点通信，获取最新redo的lsn和其描述信息。 从log store中读取redo日志到内存中。 redo 日志解析处理，失效内存中相关元数据信息、更新内存中的视图信息等。 推进visible lsn。 在大多数情况下，主节点和只读节点时延很小，但是在一些特殊场景下如主节点做大量DDL时候，可能会产生较大的只读延迟。

约束与限制 TaurusDB实例的内核版本为2.0.57.240900及以上时支持使用表回收站功能。 如果TaurusDB实例内核版本低于2.0.57.240900，且用户手动创建了名为“__recyclebin__”的数据库，则实例升级到2.0.57.240900及以上版本时，可能出现升级预检查失败。请手动删除“__recyclebin__”数据库后重新升级。如需继续保留用户创建的“__recyclebin__”数据库作为普通数据库进行使用，请提交工单处理。 表回收站功能仅支持普通innodb表，不支持共享表空间、全文索引、临时表、非innodb表、存在Secondary Engine的表、系统表、隐藏表。 当前版本表回收站仅支持单条DROP TABLE语句中，全部表都支持表回收站功能的情况。如多表删除语句中部分表支持表回收站，部分表不支持表回收站，则根据实例参数“rds_recycle_bin_mode”判断语句执行失败报错，或彻底删除全部指定表。 当前版本表回收站仅支持通过DROP TABLE命令删除表，其他删除命令会将表直接删除，无法恢复。 如实例存在基于Binlog的复制链路（如DRS 数据复制服务 、灾备实例），且回收站Binlog记录模式为ORIGIN时，在源端清理或恢复回收站中的表，可能会导致复制异常或数据不一致。建议用户设置回收站Binlog记录模式为TRANSLATE。 当前版本DRS数据复制服务暂未完整支持回收站功能。 通过DRS全量同步任务将回收站中的表复制到目标端实例，在目标端实例上无法通过调用call dbms_recyclebin.show_tables()和call dbms_recyclebin.restore_table()对回收站的表进行查询和恢复。 DRS不会同步单条DROP TABLE语句的session级回收站开关，而是根据目标端global级别回收站参数，判断DROP TABLE语句在目标端实例是否将表暂存入回收站。 源端实例回收站Binlog记录模式为ORIGIN，或Binlog记录模式为TRANSLATE，但是目标端实例为支持回收站功能的版本且DRS任务通过填写IP地址进行目标实例DRS配置时，DRS增量同步不会同步回收站的restore_table恢复和purge_table清理操作。 如因开启回收站相关功能导致复制中断，请尝试重置链路，或提交工单处理。 TaurusDB实例表回收站功能在2.0.57.240900版本仅支持表名由ASCII字符（如英文字母、数字、常见标点符号等）组成的表，其他表名字符类型（如拉丁字母、希腊字母、中文等）将在2.0.60.241200版本开放支持。 若在2.0.57.240900版本对其他暂不支持字符类型表名的表进行回收和恢复，可能出现连接卡住的情况，此时请重启数据库或执行主备倒换，实例恢复后关闭回收站，对相关表进行删除。

使用示例 表回收站功能提供以下命令用于操作回收站中暂存的表。 查看回收站中暂存的表 call dbms_recyclebin.show_tables(); 返回结果格式如下： +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | SCHEMA | TABLE | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME | PURGE_TIME | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | __recyclebin__ | __innodb_test_db_t1_1069 | test_db | t1 | 2024-09-29 08:48:27 | 2024-10-02 08:48:27 | | __recyclebin__ | __innodb_test_db_t2_1070 | test_db | t2 | 2024-09-29 08:48:44 | 2024-10-02 08:48:44 | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ 表3 字段说明 字段 说明 SCHEMA 回收站中表的当前库名。 TABLE 回收站中表的当前表名。 ORIGIN_SCHEMA 移入回收站前的原库名。 ORIGIN_TABLE 移入回收站前的原表名。 RECYCLED_TIME 表被移入回收站的时间。 PURGE_TIME 预计表被自动清理的时间。 恢复回收站中的表 手动创建与原表表结构相同的新表后，通过INSERT INTO ... SELECT ...语句将表中数据恢复到新表 示例： 查询回收站中原库名为db，原表名为t1的表： call dbms_recyclebin.show_tables(); 返回结果格式如下： +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | SCHEMA | TABLE | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME | PURGE_TIME | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ | __recyclebin__ | __innodb_test_db_t1_1069 | db | t1 | 2024-09-29 08:48:27 | 2024-10-02 08:48:27 | | __recyclebin__ | __innodb_test_db_t2_1070 | db | t2 | 2024-09-29 08:48:44 | 2024-10-02 08:48:44 | +----------------+--------------------------+---------------+--------------+---------------------+---------------------+ 通过以上查询结果，确定需要恢复的表在回收站中的当前表名为__innodb_test_db_t1_1069，执行INSERT INTO ... SELECT ...命令，将回收站中表__innodb_test_db_t1_1069的数据恢复到新创建的表t1中： INSERT INTO `db`.`t1` SELECT * FROM `__recyclebin__`.`__innodb_test_db_t1_1069`; 通过INSERT INTO ... SELECT ...语句进行恢复不会移除回收站中暂存的数据，支持多次恢复，且生成的Binlog兼容性最佳。如实例存在基于Binlog的复制链路（如DRS数据复制服务、灾备实例），请避免使用call dbms_recyclebin.restore_table命令对回收站中的表进行恢复，建议使用INSERT INTO ... SELECT ...对数据进行恢复，降低由于目标端不支持表回收站功能、用户权限不足等原因导致复制中断的风险。 恢复回收站中的表到原库原表 call dbms_recyclebin.restore_table('TABLE_NAME'); 表4 参数说明 参数名称 说明 TABLE_NAME 回收站中表的当前表名。 示例： 将回收站中表__innodb_test_db_t1_1069恢复到原库test_db，并保留原表名t1。 call dbms_recyclebin.restore_table('__innodb_test_db_t1_1069'); 恢复回收站中的表到指定库的指定表 call dbms_recyclebin.restore_table('TABLE_NAME', 'DEST_DB', 'DEST_TABLE'); 表5 参数说明 参数名称 说明 TABLE_NAME 回收站中表的当前表名。 DEST_DB 指定表恢复到的数据库。 DEST_TABLE 指定表恢复后的表名。 示例： 将回收站中表__innodb_test_db_t1_1069恢复到指定库test_db2，并指定恢复后的表名为t3。 call dbms_recyclebin.restore_table('__innodb_test_db_t1_1069','test_db2','t3'); 执行恢复操作前请确保目标库存在，否则恢复命令将执行失败。 执行恢复操作前请确认目标库下不存在同名表，否则恢复将执行失败。 表回收站相关命令指定的引号内的库名、表名前后不允许有多余空格。 清理回收站中指定表 call dbms_recyclebin.purge_table('TABLE_NAME'); 表6 参数说明 参数名称 说明 TABLE_NAME 回收站中表的当前表名。 示例： 手动清理回收站中表__innodb_test_db_t1_1069 call dbms_recyclebin.purge_table('__innodb_test_db_t1_1069');

使用限制 当前版本支持分区级MDL锁功能，包括DROP PARTITION操作、RANGE和LIST分区方式的ADD PARTITION操作。 DROP PARTITION操作和ADD PARTITION操作仅支持inplace算法，不支持copy算法。 由于隔离级别可以设置为会话级别，如果transaction_isolation设置为REPEATABLE-READ或更高的隔离级别，在并发执行DDL过程中，可能会出现如下报错： ERROR HY000: Table definition has changed, please retry transaction。 这是正常现象，因为事务访问到了DDL创建的新分区。可以通过重新执行事务来解决这个问题。

语法 扩展column_definition定义，支持在CREATE TABLE/ALTER TABLE ADD/ALTER TABLE CHANGE/ALTER TABLE MODIFY场景定义列属性时使用压缩特性。 create_definition: { col_name column_definition | {INDEX | KEY} [index_name] [index_type] (key_part,...) [index_option] ... | {FULLTEXT | SPATIAL} [INDEX | KEY] [index_name] (key_part,...) [index_option] ... | [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (key_part,...) [index_option] ... | [CONSTRAINT [symbol]] UNIQUE [INDEX | KEY] [index_name] [index_type] (key_part,...) [index_option] ... | [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (col_name,...) reference_definition | check_constraint_definition } alter_option: { table_options | ADD [COLUMN] col_name column_definition [FIRST | AFTER col_name] | ADD [COLUMN] (col_name column_definition,...) | CHANGE [COLUMN] old_col_name new_col_name column_definition [FIRST | AFTER col_name] | MODIFY [COLUMN] col_name column_definition [FIRST | AFTER col_name] ... 其中column_definition为： column_definition: { data_type [NOT NULL | NULL] [DEFAULT {literal | (expr)} ] [VISIBLE | INVISIBLE] [AUTO_INCREMENT] [UNIQUE [KEY]] [[PRIMARY] KEY] [COMMENT 'string'] [COLLATE collation_name] [COLUMN_FORMAT {FIXED | DYNAMIC | DEFAULT}] [COLUMN_FORMAT {FIXED|DYNAMIC|DEFAULT}|COMPRESSED[={ZLIB|ZSTD}**]] [ENGINE_ATTRIBUTE [=] 'string'] [SECONDARY_ENGINE_ATTRIBUTE [=] 'string'] [STORAGE {DISK | MEMORY}] [reference_definition] [check_constraint_definition] | data_type [COLLATE collation_name] [GENERATED ALWAYS] AS (expr) [VIRTUAL | STORED] [NOT NULL | NULL] [VISIBLE | INVISIBLE] [UNIQUE [KEY]] [[PRIMARY] KEY] [COMMENT 'string'] [reference_definition] [check_constraint_definition] }

特性参数说明 表1 参数说明 参数名称 描述 取值范围 默认值 级别 是否动态生效 rds_column_compression 当参数取值为0时，表示字段压缩特性关闭，不再支持显式或者自动创建压缩列。 当参数取值为1时，表示仅支持显式创建压缩列。 当参数取值为2时，表示同时支持显式或自动创建压缩列。 [0,2] 0 GLOBAL 是 rds_default_column_compression_algorithm 设置字段压缩特性默认的压缩算法，适用于如下场景： 显式创建压缩字段而不指定具体的压缩算法。 自动压缩场景。 ZLIB或ZSTD ZLIB GLOBAL 是 rds_column_compression_threshold 设置字段压缩特性的阈值。 当列定义最大长度小于此阈值时，可以显式创建压缩列，但会收到提示信息，不能自动地创建压缩列。 当列定义最大长度大于等于此阈值时，支持显式或者自动创建压缩列。 [20-4294967295] 100 GLOBAL 是 rds_zlib_column_compression_level 控制字段压缩特性中zlib压缩算法的压缩级别。 当参数取值为0时代表不压缩。 取值为除0外范围内的其他参数值时，取值越小，压缩速度越快但压缩效果越差；取值越大，压缩速度越慢但压缩效果越好。 [0,9] 6 GLOBAL 是 rds_zstd_column_compression_level 控制字段压缩特性中zstd压缩算法的压缩级别。 取值越小，压缩速度越快但压缩效果越差；取值越大，压缩速度越慢但压缩效果越好。 [1,22] 3 GLOBAL 是

使用须知 TaurusDB实例内核版本大于等于2.0.54.240600可使用该功能。 不支持分区表、临时表、非InnoDB引擎表。 压缩字段上不能包含索引(主键、唯一索引、二级索引、外键、全文索引)。 仅支持的数据类型：BLOB（包含TINYBLOB、BLOB、MEDIUMBLOB、LONGBLOB），TEXT（包含TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT），VARCHAR，VARBINARY。 不支持在生成列上使用此特性。 不支持在分区表和带有压缩字段的表之间执行EXCHANGE PARTITION式语句。 不支持IMPORT TABLESPACE。 仅支持在CREATE TABLE/ALTER TABLE ADD/ALTER TABLE CHANGE/ALTER TABLE MODIFY场景使用此特性。 ALTER TABLE ADD COLUMN不支持INSTANT算法，ALTER TABLE {CHANGE|MODIFY} 语法涉及数据变化时不支持使用INSTANT算法。 自动压缩场景(rds_column_compression=2)，定义字段的最大长度需大于等于字段压缩阈值(rds_column_compression_threshold)时才可以被添加压缩属性；显式压缩场景(rds_column_compression=1)，若定义压缩字段的最大长度小于字段压缩阈值，字段仍可被添加压缩属性，同时收到warning信息。 若当前表中包含压缩字段，暂不支持NDP计算下推。 客户手动拉取BIN LOG 同步过程中ALTER语句会出现不兼容的问题，推荐客户侧使用HINT的方式来解决。 利用DRS迁移至无该特性的实例，压缩属性被消除。全量迁移任务可以进行，增量迁移时ALTER语句中存在压缩字段会导致迁移任务失败。 物理备份方面，利用备份去做数据恢复的版本也必须是带有字段压缩特性的。 升级至新版本之后，如果已经使用字段压缩功能，不支持回退至无该特性的版本。

资源计划（plan）管理 资源计划（plan）用于控制资源计划指令（plan_directive）的启用或禁用。一个资源计划关联一个或多个资源计划指令。启用或禁用资源计划可使对应的资源计划指令生效或失效，同一个租户内至多只能启用一个资源计划。 创建资源计划 dbms_resource_manager.create_plan ( plan_name VARCHAR(128), comment VARCHAR(2000)); 若删除当前启用的资源计划，则会将当前启用的资源计划设置为空，同时删除对应的资源计划指令（plan_directive）。 plan默认可配置的最大数量为128，由参数mt_resource_plan_num控制。 参数说明： plan_name：资源计划名称，仅支持包含大写字母、小写字母、数字或下划线。 comment：资源计划描述信息，可为''。 启用或禁用资源计划 dbms_resource_manager.set_resource_manager_plan( plan_name VARCHAR(128)); 参数说明： plan_name：资源计划名称。如果为空('')，则禁用资源计划。 删除资源计划 dbms_resource_manager.delete_plan ( plan_name VARCHAR(128)); 删除当前正在启用的资源计划，则会将当前启用的资源计划设置为空，同时删除所关联的资源计划指令（plan_directive）。 参数说明： plan_name：资源计划名称。 查看资源计划 视图DBA_RSRC_PLANS记录资源计划的详细信息。如果在系统租户下查看，则可以查询到所有租户的资源计划，如果在普通租户下查看，只能看到当前租户下的资源计划。 SELECT * FROM information_schema.DBA_RSRC_PLANS;

资源计划指令(plan_directive)管理 资源计划指令描述了一个资源消费组具体的资源配置情况，一个资源计划指令唯一对应一个资源消费组；一个资源消费组可以关联多个资源计划指令，其中至多只允许启用一个资源计划指令，启用资源计划指令由上述启用资源计划实现。 创建资源计划指令 dbms_resource_manager.create_plan_directive ( plan CHAR(128), group_or_subplan CHAR(128), comment VARCHAR(2000), mgmt_p1 bigint(20), utilization_limit bigint(20)); 同一资源消费组下的用户共享当前启用的资源计划指令配置的资源。例如：同一租户下的用户user1和user2都添加到资源消费组consumer_group1中，consumer_group1当前启用的资源计划指令的UTILIZATION_LIMIT为70，mgmt_p1为10，则user1和user2可使用的CPU资源总和最大为当前租户70%，CPU争抢时，保证user1和user2可获得的CPU资源总和为当前租户10%。 参数说明： plan：资源计划(plan)的名称。 group_or_subplan：资源消费组(consumer_group)的名称。 comment：资源计划指令的描述信息，可为''。 mgmt_p1：在CPU资源争抢的情况下，承诺分配给本资源消费组的CPU资源占所属租户总CPU资源的比例，取值范围[0, 100]，表示使用所属租户100%的CPU。同一租户且同一个资源计划(plan)所关联的所有资源计划指令(plan_directive)的mgmt_p1总和不超过100。当租户内的各个资源消费组发生CPU争抢，优先保证承诺分配各个资源消费组CPU资源，剩余的CPU资源由各个资源消费组争抢。承诺分配给资源消费组的CPU资源也遵循按需分配策略，不会预留，例如：承诺给当前资源消费组20%的CPU资源，但当前资源消费组业务量较少，只需要5%的CPU资源，则剩余的15%的CPU资源会按需分配给其他资源消费组。 utilization_limit：资源消费组可用的CPU资源的上限占所属租户总CPU资源的比例，取值范围为 [1, 100]。表示最大可使用租户全部CPU资源，如果取值为70则表示最大可使用租户70%的CPU资源。 更新资源计划指令 dbms_resource_manager.update_plan_directive ( plan CHAR(128), group_or_subplan CHAR(128), new_comment VARCHAR(2000), new_mgmt_p1 bigint(20), new_utilization_limit bigint(20)); 同一资源消费组下的用户共享当前启用的资源计划指令配置的资源。例如：同一租户下的用户user1和user2都添加到资源消费组consumer_group1中，consumer_group1当前启用的资源计划指令的UTILIZATION_LIMIT为70，mgmt_p1为10，则user1和user2可使用的CPU资源总和最大为当前租户70%，CPU争抢时，保证user1和user2可获得的CPU资源总和为当前租户10%。 参数说明： plan：资源计划(plan)的名称。 group_or_subplan：资源消费组(consumer_group)的名称。 comment：资源计划指令的描述信息，可为''。 mgmt_p1：在CPU资源争抢的情况下，承诺分配给本资源消费组的CPU资源占所属租户总CPU资源的比例，取值范围[0, 100]，表示使用所属租户100%的CPU。同一租户且同一个资源计划(plan)所关联的所有资源计划指令(plan_directive)的mgmt_p1总和不超过100。当租户内的各个资源消费组发生CPU争抢，优先保证承诺分配各个资源消费组CPU资源，剩余的CPU资源由各个资源消费组争抢。承诺分配给资源消费组的CPU资源也遵循按需分配策略，不会预留，例如：承诺给当前资源消费组20%的CPU资源，但当前资源消费组业务量较少，只需要5%的CPU资源，则剩余的15%的CPU资源会按需分配给其他资源消费组。 utilization_limit：资源消费组可用的CPU资源的上限占所属租户总CPU资源的比例，取值范围为 [1, 100]。表示最大可使用租户全部CPU资源，如果取值为70则表示最大可使用租户 70%的CPU资源。 删除资源计划指令 dbms_resource_manager.delete_plan_directive ( plan CHAR(128), group_or_subplan VARCHAR(128)); 删除正在启用的plan_directive, 将导致对应用户的资源配置失效。 参数说明： plan：资源计划(plan)的名称。 group_or_subplan：资源消费组(consumer_group)的名称。 查看资源计划指令 DBA_RSRC_PLAN_DIRECTIVES记录资源计划指令的详细信息。如果在系统租户下查看，则可以查询到所有租户的资源计划指令，如果在普通租户下查看，只能看到当前租户下的资源计划指令。 SELECT * FROM information_schema.DBA_RSRC_PLAN_DIRECTIVES;

CPU使用率统计 用户级CPU使用率 新增information_schema.cpu_summary_by_user视图，用于显示各个资源消费组的CPU使用信息，在系统租户下会显示所有租户的所有资源消费组的CPU使用信息，在普通租户下，只会显示当前租户的所有资源消费组的CPU使用信息，具体使用如下： SELECT * FROM information_schema.cpu_summary_by_user; 查询结果中的列名说明： TENANT_NAME：用户所属的租户名称。 CONSUMER_GROUP：资源消费组名称。 CPU_USAGE：资源消费组的CPU使用率，为使用的CPU占所在实例总CPU的比例。例如4U的实例中, 资源消费组实际用了2U， 那么CPU_USAGE为50%。 CPU_USAGE_RELATIVE：资源消费组的CPU相对使用率，为使用的CPU占所在租户配置的MAX_CPU的比例。例如，当前租户的max_cpu为4U, 而资源消费组实际用了2U， 那么CPU_USAGE_RELATIVE为50%。 INCLUDED_USERS：属于此资源消费组中的用户名。 独占租户会创建一个默认的资源消费组default_group，租户下所有未绑定具体资源消费组的用户都会归属到default_group，default_group默认可使用租户的所有CPU资源，当租户内CPU争抢时，优先保证承诺分配给其他资源消费组的CPU资源，剩余的CPU资源分配给default_group。 租户级CPU使用率 新增information_schema.cpu_summary_by_tenant视图，用于显示各租户的CPU使用信息，在系统租户下会显示所有租户的CPU使用信息，在普通租户下，只会显示当前租户的CPU使用信息，具体使用如下： SELECT * FROM information_schema.cpu_summary_by_tenant; 查询结果中的列名说明： TENANT_NAME：租户名称。 TENANT_TYPE：租户类型，exclusive表示独占租户，shared表示共享租户。 CPU_USAGE：租户的CPU使用率，为使用的CPU占所在实例总CPU的比例。例如4U的实例中, 租户实际用了2U， 那么CPU_USAGE为50%。 CPU_USAGE_RELATIVE：租户CPU相对使用率，为租户实际使用的CPU占配置的MAX_CPU的占比。例如，当前租户的max_cpu为4U, 而租户实际用了2U， 那么CPU_USAGE为50%。 在满足所有独占租户MIN_CPU所配置的CPU资源后，所有的共享租户共享剩余的CPU资源，所以视图中所有的共享租户的CPU使用率一样，为所有共享租户的CPU使用率的总和。

用户级资源配置 租户下的用户默认共享当前租户的资源，若要进行用户级资源限制，请使用本节提供的用户级资源配置接口。 共享租户无法进行用户级资源配置。 资源消费组（consumer_group）管理 多个用户可以归属到同一个资源消费组(consumer_group)，这些用户共享资源消费组所关联的资源，通过租户下的用户连接数据库，进行资源消费组管理。 创建消费组 dbms_resource_manager.create_consumer_group ( consumer_group CHAR(128), comment CHAR(2000)); 参数说明： consumer_group：资源消费组名称，仅支持包含大写字母、小写字母、数字或下划线。 comment：资源消费组说明，可为''。 添加用户到资源消费组/从资源消费组中移除用户 dbms_resource_manager.set_consumer_group_mapping ( attribute CHAR(128), value varbinary(128), consumer_group CHAR(128)); 参数说明： attribute：要添加或修改的映射属性，当前版本仅支持USER。 value：要添加或修改的映射属性，当前版本仅支持用户名。 consumer_group：资源消费组名称，当参数不为空时将用户添加到资源消费组，当参数为空('')时，将用户从所在的资源消费组中移除。 删除消费组 dbms_resource_manager.delete_consumer_group ( consumer_group CHAR(128)); 参数说明： consumer_group：资源消费组名称。 删除consumer_group的时候会同步删除该资源消费组对应的plan_directive以及consumer_group_mapping。 如果特性开关打开，删除用户时，会自动将用户从已关联的资源消费组中移除。当特性关闭时，删除用户时不会自动从已关联的资源消费组中移除，但不会有任何影响，当后续重新打开特性时，如果发现关联到资源消费组的用户已经被删除，会自动将这些用户从已关联的资源消费组中移除。 如果特性开关打开，重命名用户时，不影响用户与资源消费组的关联关系。如果特性开关关闭后，删除用户，再创建同名用户，后续打开特性，该用户依然属于原有的资源消费组。 查看资源消费组 视图DBA_RSRC_CONSUMER_GROUPS记录了资源消费组信息。如果以系统租户下的用户身份下查看，则可以查询到所有租户的资源消费组信息，如果在普通租户下查看，只能看到当前租户下的资源消费组信息。 select * from information_schema.DBA_RSRC_CONSUMER_GROUPS; 查看资源消费组和用户的关联关系 视图DBA_RSRC_GROUP_MAPPINGS记录了用户和资源消费组的关联关系。如果以系统租户下的用户身份下查看，则可以查询到所有租户的用户和资源消费组的关联关系，如果在普通租户下查看，只能看到当前租户下的用户和资源消费组的关联关系。 select * from information_schema.DBA_RSRC_GROUP_MAPPINGS;

资源管理 资源配置（resource_config）和租户是一对多的关系，当某一租户绑定此资源配置时便可限制此租户下用户使用的CPU资源。仅在高权限root用户下可使用。 创建资源配置 CREATE resource_config config_name MAX_CPU [=] max_cpu_value [MIN_CPU [=] min_cpu_value]; 更新资源配置 ALTER resource_config config_name MAX_CPU [=] max_cpu_value [MIN_CPU [=] min_cpu_value]; 删除资源配置 DROP resource_config config_name; 查看资源配置 SELECT * FROM information_schema.DBA_RSRC_TENANT_RESOURCE_CONFIGS; 表2 参数说明 参数 描述 config_name 资源配置名称。最大长度为64，仅支持包含大写字母、小写字母、数字或下划线。 MAX_CPU 绑定该资源配置的租户能够使用的最大CPU资源，单位为核数，最小值为0.1，最大值为实例规格中的CPU核数，可查看变量mt_flavor_cpu获取。粒度0.1。 MIN_CPU 在CPU资源争抢时，承诺分配给绑定该资源配置的租户的CPU资源，单位为核数，为可选项。默认等于MAX_CPU，最小值为0.1，最大值不超过MAX_CPU。粒度为0.1。(shared_tenants_config为系统内置的资源配置，其MIN_CPU为0)。承诺分配给租户的CPU资源遵循按需分配策略，不会预留，例如：承诺给租户分配1U，但如果租户业务空闲，只会使用0.3U，则剩余的0.7U会按需分配给其他租户。 更新resource_config时，如果该resource_config已经绑定租户，且更新后MIN_CPU值大于原有的MIN_CPU值，则需要校验修改后的值是否满足资源约束，否则不做资源约束校验。 删除resource_config时，若租户正在使用该资源配置，则无法进行删除操作。 CPU争抢时，租户间资源分配会尽量按照租户的MIN_CPU分配资源，但存在一定的误差，误差通常在1U以内。 各租户下的实例的读写性能峰值并非和分配到的CPU资源呈线性关系。例如16U的实例分配给2个租户的MAX_CPU均为8U，那么两个租户同时满载跑业务的总共的TPS将达不到8U实例的2倍。即租户下的实例性能可能比同等规格的非多租实例的性能稍低。

表空间管理 当前实现了通用表空间GENERAL TABLESPACE的租户间隔离，其中TABLESPACE分为系统租户下的TABLESPACE和普通租户下的TABLESPACE。系统租户可以访问所有TABLESPACE，普通租户只能访问属于自己的TABLESPACE。在升级和迁移场景下，存量的TABLESPACE不做改动，统一归属于系统租户的TABLESPACE。 在系统租户下管理表空间 创建表空间 创建系统租户的表空间 CREATE TABLESPACE `tablespace_name`; CREATE TABLESPACE `tablespace_name` add datafile `tablespace_file_name.ibd`; 创建普通租户的表空间 CREATE TABLESPACE `tablespace_name@tenant_name`; CREATE TABLESPACE `tablespace_name@tenant_name` add datafile `tablespace_file_name.ibd`; 删除表空间 删除系统租户的表空间 DROP TABLESPACE `tablespace_name`; 删除普通租户的表空间 DROP TABLESPACE `tablespace_name@tenant_name`; 重命名表空间 重命名系统租户的表空间 ALTER TABLESPACE `tablespace_name` RENAME TO `tablespace_name`; 重命名普通租户的表空间 ALTER TABLESPACE ` tablespace_name@tenant_name ` RENAME TO `new_tablespace_name@tenant_name`; 表空间与表绑定 创建系统租户下的表，并与指定TABLESPACE关联 CREATE TABLE table_name … TABLESPACE [=] `tablespace_name`; 创建普通租户下的表，并与指定TABLESPACE关联 CREATE TABLE table_name … TABLESPACE [=] `tablespace_name@tenant_name`; 将系统租户下的存量表与指定TABLESPACE关联 ALTER TABLE table_name TABLESPACE `tablespace_name`; 将普通租户下的存量表到指定TABLESPACE关联 ALTER TABLE table_name TABLESPACE `tablespace_name@tenant_name`; 在普通租户下管理表空间 创建当前租户的表空间 CREATE TABLESPACE `tablespace_name`; 删除当前租户的表空间 DROP TABLESPACE `tablespace_name`; 重命名当前租户的表空间 ALTER TABLESPACE `tablespace_name` RENAME TO ` tablespace_name `; 创建当前租户的表，并与指定TABLESPACE关联 CREATE TABLE table_name … TABLESPACE [=] tablespace_name; 将当前租户的存量表与指定TABLESPACE关联 ALTER TABLE table_name TABLESPACE `tablespace_name`; 启用多租开关后，tablespace名称的最大长度由64降低到50，且不能包含`@`字符。 特殊的tablespace无法被创建，如以`innodb_`开头的tablespace无法被创建。 若某个租户创建的tablespace的datafile与自己或者其他租户创建的tablespace的datafile相同，那么这个租户此次创建的tablespace会失败。 在系统租户下将普通租户的表与tablespace进行绑定，若新的tablespace的名字以innodb_开头，说明此tablespace为系统tablespace，此时tablespace_name不用带上@tenant_name。 在系统租户下将普通租户的表与普通租户的tablespace进行绑定, 需要表和tablespace属于同一个tenant。

用户管理 开启多租模式后，用户分为系统租户下的用户和普通租户下的用户。存量的用户均属于系统租户，新创的用户根据接口语义属于系统租户或者普通租户。 在系统租户下管理用户 创建用户 创建系统租户下的用户： CREATE user [IF NOT EXISTS] user_name@'host'; 创建普通租户下的用户： CREATE user [IF NOT EXISTS] 'user_name@tenant_name'@'host'; 重命名用户 重命名系统租户下的用户： RENAME USER user_from@host1 TO user_to@'host'; 重命名普通租户下的用户： RENAME USER 'user_from@tenant_name'@host1 TO 'user_to@tenant_name'@'host'; 删除用户 删除系统租户下的用户： DROP USER [IF EXISTS] user_name@'host'; 删除普通租户下的用户： DROP USER [IF EXISTS] 'user_name@tenant_name'@'host'; 授权用户 为用户'user_1@tenant_1'@'%'授予租户tenant_1下的priv_type权限： GRANT priv_type ON *.* to 'user_1@tenant_1'@'%' with grant option; 查看权限： SHOW grants for 'user_1@tenant_1'@'%'; 在普通租户下管理用户 创建用户 创建当前租户下的用户： CREATE user [IF NOT EXISTS] user_name@'host'; 重命名用户 RENAME USER user_from@host1 TO user_to@'host'; 删除用户 DROP USER [IF EXISTS] user_name@'host'; 授权用户 为用户user1授予当前租户下的priv_type权限： GRANT priv_type ON *.* to 'user_1'@'%' with grant option; 查看权限： SHOW grants for 'user_1'; 以系统租户身份创建或删除普通租户下的用户时，需要以user_name@tenant_name的方式对用户进行操作。 普通租户下的用户名称的长度被限制为不超过20个字符。 租户内不可以创建部分特殊用户：mysql.sys, mysql.session, mysql.infoschema以及参数rds_reserved_users中保留的用户。 在系统租户下，对普通租户下的用户重命名时，需要保证user_from和user_to中的tenant_name相同，如不相同，则接口返错。 多租户隔离特性关闭时，无法重命名普通租户下的用户。

数据库管理 数据库分为系统租户下的数据库和普通租户下的数据库。系统租户可以访问所有数据库，普通租户只能访问属于自己的数据库。 在系统租户下需要以db_name@tenant_name的方式对普通租户下的数据库进行操作。 系统库SYS、MYSQL暂不允许普通租户访问。 租户内不可以创建部分特殊DB：INFORMATION_SCHEMA, PERFORMANCE_SCHEMA, MYSQL, SYS, __recyclebin__。 在系统租户下管理数据库 创建数据库 创建系统租户的数据库： CREATE DATABASE [IF NOT EXISTS] `db_name`; 创建普通租户的数据库： CREATE DATABASE [IF NOT EXISTS] `db_name@tanant_name`; 删除数据库 删除系统租户的数据库： DROP DATABASE [IF EXISTS] `db_name`; 删除普通租户的数据库： DROP DATABASE [IF EXISTS] `db_name@tanant_name`; 在普通租户下管理数据库 创建当前租户的数据库： CREATE DATABASE [IF NOT EXISTS] 'db_name'; 删除当前租户的数据库： DROP DATABASE [IF EXISTS] 'db_name'; 存量数据库分配租户 为保证兼容性，升级或者迁移到多租实例后，存量的数据库默认属于系统租户，可以通过如下语法将存量的数据库分配给租户。此外，对于已经开启多租特性后，系统租户创建的且未分配给普通租户的数据库，也可通过如下语法分配数据库给对应租户。 数据库分配 将数据库分配给租户名为tenant_name的普通租户 ALTER DATABASE db_name TENANT = `tenant_name`; 将数据库回收到系统租户下 ALTER DATABASE db_name TENANT = ``; 查看映射关系 SELECT * FROM information_schema.DBA_RSRC_TENANT_DB; 仅在高权限root用户下可使用。 如果数据库是开启多租后创建的，以db_name@tenant_name格式命名的数据库不允许分配调用此接口，接口会返错。 如果tenant不存在，且不为空，接口返错。 通过租户下的用户连接数据库 在系统租户下，原有连接方式不变。 在普通租户下，指定用户时，需要以user_name@tenant_name的形式；指定数据库时，支持db_name和db_name@tenant_name两种形式。 mysql --host=**** -u user1@tenant_1 -D db1 -p password; mysql --host=**** -u user1@tenant_1 -D db1@tenant_1 -p password; 连接成功后，该用户将受到对应租户下的资源限制。

使用须知 多租户管理与资源隔离功能支持租户级数据隔离、租户级CPU资源隔离、用户级CPU资源隔离。 多租户管理与资源隔离功能需要TaurusDB实例内核版本为2.0.57.240900及以上。 开启多租户管理与资源隔离前必须开启thread pool功能。 开启多租户管理与资源隔离功能前，要求实例中的数据库名称、用户名称、表空间名称不能包含@字符。 Serverless不支持多租户管理与资源隔离功能。 若TaurusDB实例内核版本2.0.60.241200及其以上，新增的多租视图（包括MT_RESOURCE_CONFIG、MT_TENANT、MT_TENANT_DB、MT_RESOURCE_PLAN、MT_CONSUMER_GROUP、MT_GROUP_MAPPING_RULE、MT_PLAN_DIRECTIVE）将代替旧版本的多租视图DBA_RSRC_*提供服务。 Binlog： 目前Binlog没有实现租户隔离，如果允许普通租户拉取Binlog会破坏租户间数据隔离，因此当前禁止普通租户下的用户拉取Binlog。 数据库代理： 因HTAP标准版和轻量版不支持带@字符的数据库，普通租户下的数据库迁移到该类HTAP引擎时会更改目标端库名，但数据库代理的自动行存/列存引流功能要求源端和目标端的库名一致，因此普通租户创建的数据库将无法使用数据库代理的自动行存/列存引流功能。 备份恢复： 恢复已打开过多租开关的多租实例数据到新实例，未开启多租开关下，新实例不支持创建带@的用户、数据库和表空间。 升降级： 如果实例中的多租开关打开，且TaurusDB实例内核版本为2.0.60.241200及其以上，存在需要降级到2.0.60.241200之前的版本的场景。降级成功后，需要再次重启实例，多租功能才能恢复可用，否则降级后的多租开关将变更为关闭。 如果TaurusDB实例内核版本为2.0.60.241200及其以上，存在需要降级到2.0.60.241200之前的版本的场景。降级成功后，在information_schema下执行show tables等可能会依然会显示新增的多租视图（包括MT_RESOURCE_CONFIG、MT_TENANT、MT_TENANT_DB、MT_RESOURCE_PLAN、MT_CONSUMER_GROUP、MT_GROUP_MAPPING_RULE、MT_PLAN_DIRECTIVE），但无法访问。如需清除残留的多租视图元数据，需要手动重启实例。 如果TaurusDB实例内核升级到2.0.60.241200版本及以后，在information_schema下执行show tables命令，可能无法正常显示新增的多租视图。但不影响多租视图的访问，如需显示，需要手动重启实例。 兼容性： 先开启后关闭多租开关，创建数据库、用户和表空间时，名称中不能包含@字符。 普通租户下，数据库名称最大长度由64降低为50，用户名称最大长度由32降低为20。 系统库mysql、sys暂不开放给普通租户。 普通租户下，系统库performance_schema里的表使用用户名或库名做条件查询时，需要使用模糊搜索。 系统租户的root用户可以kill其他用户的session；普通租户的用户，只能kill当前用户的session。 多租实例不支持全文索引。

租户管理 创建租户时，需要绑定已经创建的资源配置（resource_config），以此限制该租户下用户使用的CPU资源。仅在高权限root用户下可使用。 创建租户 CREATE TENANT tenant_name RESOURCE_CONFIG config_name [COMMENT [=] 'comment_string']; tenant_name长度不超过10个字符，仅支持包含小写字母、数字或下划线_。 创建租户会进行资源约束检查，需要保证所有租户的资源配置中MIN_CPU之和满足资源约束。 如果租户绑定shared_tenants_config，则租户成为共享租户，否则是独占租户。当发生资源争抢时，优先满足独占租户的MIN_CPU承诺资源需求，剩余的资源再由共享租户和独占租户争抢。 租户间资源充分利用。 例如8U实例，分配给租户A的MIN_CPU是3U，MAX_CPU是8U。分配给租户B的MIN_CPU是5U，MAX_CPU是8U。当租户A没有负载情况下，租户B可以使用到8U。如果租户A负载1U，则租户B可使用7U。 更改租户 ALTER TENANT tenant_name RESOURCE_CONFIG config_name [COMMENT [=] 'comment_string']; 如果新绑定的resource_config的MIN_CPU值大于等于原有resource_config的MIN_CPU值时，会进行资源约束检查，需要保证所有租户的资源配置中MIN_CPU之和满足资源约束。 如果独占租户新绑定到shared_tenants_config，则成为共享租户，将同时删除租户下的用户级资源隔离相关的配置。 删除租户 DROP TENANT tenant_name; 需要保证租户下的DB和用户已经被删除，否则，无法删除租户。 删除租户的同时将删除租户关联的用户级资源隔离相关的配置。 查看租户 SELECT * FROM information_schema.DBA_RSRC_TENANT;

使用示例 创建表，准备数据。 CREATE TABLE test.hotspot1 ( `id` int NOT NULL primary key, `c` int NOT NULL DEFAULT '0' ) ENGINE=InnoDB; INSERT INTO test.hotspot1 VALUES (1, 1); 打开热点行更新开关。 SET GLOBAL rds_hotspot = ON; 修改隔离级别，AUTOCOMMIT。 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; SET SESSION AUTOCOMMIT = ON; 发起带HOTSPOT关键字的更新。 UPDATE test.hotspot1 SET c=c+1 WHERE id=1 HOTSPOT; 检查热点行更新状态。 SHOW STATUS like "%hotspot%";

新增关键字 新增标记语句的关键字如下： 表3 新增关键字 关键字 描述 HOTSPOT 表示开启热点更新功能。 NOT_MORE_THAN 可选项。表示目标值不大于某值。 NOT_LESS_THAN 可选项。表示目标值不小于某值。 上述关键字放置在SQL语句末尾。HOTSPOT必须在最前面，NOT_MORE_THAN和NOT_LESS_THAN没有位置前后的要求。 例如：假设id是主键列，c是int类型列，那么支持以下语法： UPDATE c=c+1 where id=10 HOTSPOT; UPDATE c=c+1 where id=10 HOTSPOT NOT_MORE_THAN 100; // c值不大于100 UPDATE c=c-1 where id=10 HOTSPOT NOT_LESS_THAN 0; // c值不小于0 UPDATE c=c+1 where id=10 HOTSPOT NOT_MORE_THAN 100 NOT_LESS_THAN 0; // c值不大于100，不小于0 UPDATE c=c+1 where id=10 HOTSPOT NOT_LESS_THAN 0 NOT_MORE_THAN 100; // c值不大于100，不小于0 当超过NOT_MORE_THAN或者NOT_LESS_THAN的限制时，会向客户端报如下错误： HOTSPOT field value exceeds limit

性能测试 测试环境 实例规格：8U32GB、32U128GB E CS 规格：32U64GB 测试环境：华北-北京四 测试工具：sysbench-1.0.18 数据模型： 1张表，1条数据。 8张表，每张表1条数据。 参数配置 rds_hotspot=ON transaction_isolation=READ-COMMITTED max_prepared_stmt_count=1048576 rds_global_sql_log_bin=OFF 测试方法 测试所需数据表定义： CREATE TABLE sbtest (id int NOT NULL AUTO_INCREMENT,k int NOT NULL DEFAULT '0',PRIMARY KEY (id)); 测试语句： UPDATE sbtest%u SET k=k+1 WHERE id=1 hotspot； 测试场景和测试结果 测试场景1：8U32GB实例单个热点行更新 测试结果：所有并发均有不同程度提升，64并发及以下并发提升不明显，128并发及以上并发提升明显，最高提升9.26倍。 测试场景2：32U128GB实例单个热点行更新 测试结果：128并发及以上并发提升明显，最高提升639倍。 测试场景3：32U 128GB实例8个热点行更新 测试结果：256及以下并发无提升，512及以上并发提升效果明显，最高提升78倍。

约束与限制 TaurusDB实例的内核版本为2.0.54.240600及以上时支持使用该功能。 功能使用约束如下： where条件中只能使用主键或唯一索引的等值匹配，并且只能更新单条记录。否则将绕过优化正常更新。 不允许修改索引列，否则将绕过优化正常更新。 只对修改列为整数的更新生效，否则将绕过优化正常更新。 只允许对热点行记录进行两个元素的加减操作，且第一个元素与等号左侧相等并满足唯一索引等约束，不允许赋值操作。假设c列为待修改列，d为记录的普通列，那么只允许进行类似c=c+1，或者c=c-1的操作，不允许进行c=d+1，c=1+c，c=c+1+1，c=1+c+1等操作。否则将绕过优化正常更新。 只允许对隐式事务生效。即要求AUTOCOMMIT为ON，并且不在BEGIN，COMMIT显示开启的事务中使用。否则将绕过优化正常更新。 需要使用HOTSPOT显式标记热点行更新事务，或者将rds_hotspot_auto_detection_threshold设置为非0，开启热点行更新自动识别功能。否则将绕过优化正常更新。rds_hotspot_auto_detection_threshold的详细用法请见参数说明。 只对RC级别生效。数据库处于其他隔离级别时将绕过优化正常更新。 无法在stored function, trigger以及event中使用，否则将对客户端报如下错误： HOTSPOT hints can not be used in stored function, trigger or event 行为变更： 一个hotspot事务组内，除了执行失败或者在更新阶段killed的事务外，其他事务被按批次集中提交，集中记录redo log和undo log，只能集中提交或者回滚，无法单独回滚。每个批次提交的事务个数为几十到几百个不等。