华为云用户手册

2.0.28.9 表14 2.0.28.9版本说明 日期 特性描述 2022-09-23 修复在Condition_pushdown::replace_columns_in_cond中使用不正确的条件判断的问题。 修复递归调用存储函数之后导致数据库崩溃的问题。 修改多表删除和full-text搜索的时候导致数据库崩溃的问题； 修复运行多个窗口函数的SQL查询语句之后导致数据库崩溃的问题； 修复具有全局级别权限的用户，执行SHOW CREATE DATABASE失败的问题。

2.0.45.230900 表5 2.0.45.230900内核版本说明 日期 特性描述 2023-11-24 新增功能和性能优化： 优化datatime/timestamp/time字段行为向前兼容。 优化PQ支持并行磁盘hash join场景。 启用并行INSERT/REPLACE SELECT的功能优化查询速度。 增加连接建立/断开日志打印，提高定位连接相关问题效率。 优化慢日志中增加对慢SQL问题定位有用的信息，提升定位慢SQL定位效率。 支持动态开启Binlog。 优化NDP bloom过滤器。 支持使用CAST(... AS INT) 语法。 优化Nested Loop Join + Distinct 性能。 优化快速识别慢IO对应的slice id。 增加sal_init日志，后续出现存储接口超时，时延可定位性增强。 问题修复： 修复全量SQL中缺少trx_id和cpu_time字段的问题。 修复prepare语句中where比较时，字段是int类型、参数是字符串导致转换有误的问题。 修复备机上DDL与查询的并发访问时，极小概率导致crash的问题。 修复Binlog数量短期暴涨未及时清理的问题。 修复多表JOIN SQL语句打开PQ开关后，可能出现执行结果不一致的问题。 修复Backwad Index Scan与ICP无法兼容导致查询性能不及预期的问题。 修复weight_string函数不支持level子句的问题。 修复特殊场景下，相同的SQL语句选用不同的索引得出结果不一致的问题。 修复部分场景下，同时开启NDP和PQ特性recycle lsn长时间不推进的问题。

2.0.28.1 表17 2.0.28.1版本说明 日期 特性描述 2022-05-16 新特性 GaussDB (for MySQL)增加orphaned definer check控制开关。 GaussDB(for MySQL)支持Proxy IP透传。 GaussDB(for MySQL) Proxy提供会话一致性功能。 问题修复 修复主机DDL未提交导致的备机dd（data dictionary）未更新问题。 修复故障切换的主机的auto increment回退的问题。 修复备机性能异常问题。

2.0.54.240600 表2 2.0.54.240600内核版本说明 日期 特性描述 2024-07-19 新增功能和性能优化： 热点行更新优化：热点行出现的场景包括秒杀抢购、演唱会门票预订、热门路线火车票预定等等，本版本支持热点行更新优化，您可以通过手动指定或者自动识别的方式开启热点行更新，该功能开启后可以大幅度提升热点行的更新性能。 非阻塞DDL：用户在执行DDL操作的时候，如果目标表存在未提交的长事务或大查询，DDL将持续等待获取MDL-X锁，将导致业务连接的堆积和阻塞。本版本支持非阻塞DDL功能，可以保证即使在无法获得MDL-X锁的情况下，依然允许新事务进入目标表，从而保证整个业务系统的稳定。 多租户管理：提供多租户管理功能，让数据库能够为其多个租户服务，提高数据库资源利用率。 只读节点支持Binlog拉取：支持只读节点拉取Binlog，您可以以GaussDB(for MySQL)只读节点为数据源，建立Binlog复制链路，实时同步Binlog内容，以便减轻GaussDB(for MySQL)主节点的负载。 字段压缩（列压缩）：为了减少数据页面存储空间占用，节省成本，GaussDB(for MySQL)推出细粒度的字段压缩，提供ZLIB和ZSTD两种压缩算法，用户可以综合考虑压缩比和压缩解压性能影响，选择合适的压缩算法，对不频繁访问的大字段进行压缩。 支持INTERVAL RANGE分区表：现有的RANGE分区表插入数据时，如果插入的数据超出当前已存在分区的范围，将无法插入并且会返回错误。本版本支持INTERVAL RANGE分区表后，当新插入的数据超过现有分区的范围时，允许数据库根据INTERVAL子句提前指定的规则来添加新分区。 支持LIST DEFAULT HASH分区表特性：LIST DEFAULT HASH是在同一级别支持两种分区类型：LIST和HASH。前面是普通的LIST分区，不符合LIST分区规则的数据会放在DEFAULT分区里，DEFAULT分区如果有多个分区则根据HASH规则计算。LIST DEFAULT HASH分区类型常用在LIST VALUES分布不均匀以及无法全部枚举的场景。 问题修复： 优化表级恢复性能。 优化大规格实例高并发场景备机的执行性能。

资源管理 资源配置（resource_config）和租户是一对多的关系，当某一租户绑定此资源配置时便可限制此租户下用户使用的CPU资源。 创建资源配置 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; 仅在高权限root用户下可使用。 参数说明： 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倍。即租户下的实例性能可能比同等规格的非多租实例的性能稍低。

用户级资源配置 租户下的用户默认共享当前租户的资源，若要进行用户级资源限制，请使用本节提供的用户级资源配置接口。 共享租户无法进行用户级资源配置。 资源消费组（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资源。 创建租户 CREATE TENANT tenant_name RESOURCE_CONFIG config_name [COMMENT [=] 'comment_string']; 更改租户 ALTER TENANT tenant_name RESOURCE_CONFIG config_name [COMMENT [=] 'comment_string']; 删除租户 DROP TENANT tenant_name; 查看租户 SELECT * FROM information_schema.DBA_RSRC_TENANT; 仅在高权限root用户下可使用。 创建租户 tenant_name长度不超过10个字符，仅支持包含小写字母、数字或下划线_。 创建租户会进行资源约束检查，需要保证所有租户的资源配置中MIN_CPU之和满足资源约束。 如果租户绑定shared_tenants_config，则租户成为共享租户，否则是独占租户。当发生资源争抢时，优先满足独占租户的MIN_CPU承诺资源需求，剩余的资源再由共享租户和独占租户争抢。 更改租户resource_config 如果新绑定的resource_config的MIN_CPU值大于等于原有resource_config的MIN_CPU值时，会进行资源约束检查，需要保证所有租户的资源配置中MIN_CPU之和满足资源约束。 如果独占租户新绑定到shared_tenants_config，则成为共享租户，将同时删除租户下的用户级资源隔离相关的配置。 删除租户 需要保证租户下的DB和用户已经被删除，否则，无法删除租户。 删除租户的同时将删除租户关联的用户级资源隔离相关的配置。

资源计划指令(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)); 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资源。 同一资源消费组下的用户共享当前启用的资源计划指令配置的资源。例如：同一租户下的用户user1和user2都添加到资源消费组consumer_group1中，consumer_group1当前启用的资源计划指令的UTILIZATION_LIMIT为70，mgmt_p1为10，则user1和user2可使用的CPU资源总和最大为当前租户70%，CPU争抢时，保证user1和user2可获得的CPU资源总和为当前租户10%。 更新资源计划指令 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)); 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资源。 同一资源消费组下的用户共享当前启用的资源计划指令配置的资源。例如：同一租户下的用户user1和user2都添加到资源消费组consumer_group1中，consumer_group1当前启用的资源计划指令的UTILIZATION_LIMIT为70，mgmt_p1为10，则user1和user2可使用的CPU资源总和最大为当前租户70%，CPU争抢时，保证user1和user2可获得的CPU资源总和为当前租户10%。 删除资源计划指令 dbms_resource_manager.delete_plan_directive ( plan CHAR(128), group_or_subplan VARCHAR(128)); plan：资源计划(plan)的名称。 group_or_subplan：资源消费组(consumer_group)的名称。 删除正在启用的plan_directive, 将导致对应用户的资源配置失效。 查看资源计划指令 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使用率的总和。

用户管理 开启多租模式后，用户分为系统租户下的用户和普通租户下的用户。存量的用户均属于系统租户，新创的用户根据接口语义属于系统租户或者普通租户。 在系统租户下管理用户 创建用户 创建系统租户下的用户： 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@host2; 重命名普通租户下的用户： RENAME USER 'user_from@tenant_name'@host1 TO 'user_to@tenant_name'@host2; 删除用户 删除系统租户下的用户： 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@host2; 删除用户 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相同，如不相同，则接口返错。 多租户隔离特性关闭时，无法重命名普通租户下的用户。

数据库管理 数据库分为系统租户下的数据库和普通租户下的数据库。系统租户可以访问所有数据库，普通租户只能访问属于自己的数据库。 在系统租户下管理数据库 创建数据库 创建系统租户的数据库： 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'; 在系统租户下需要以db_name@tenant_name的方式对普通租户下的数据库进行操作。 系统库SYS、MYSQL暂不允许普通租户访问。 租户内不可以创建部分特殊DB：INFORMATION_SCHEMA, PERFORMANCE_SCHEMA, MYSQL, SYS, __recyclebin__。 存量数据库分配租户 为保证兼容性，升级或者迁移到多租实例后，存量的数据库默认属于系统租户，可以通过如下语法将存量的数据库分配给租户。此外，对于已经开启多租特性后，系统租户创建的且未分配给普通租户的数据库，也可通过如下语法分配数据库给对应租户。 数据库分配 将数据库分配给租户名为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 pwssword; mysql --host=**** -u user1@tenant_1 -D db1@tenant_1 -p pwssword; 连接成功后，该用户将受到对应租户下的资源限制。

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

使用须知 多租户管理与资源隔离功能支持租户级数据隔离、租户级CPU资源隔离、用户级CPU资源隔离。 多租户管理与资源隔离功能需要GaussDB(for MySQL)实例内核版本为2.0.57.240900及以上。 开启多租户管理与资源隔离前必须开启thread pool功能。 开启多租户管理与资源隔离功能前，要求实例中的数据库名称、用户名称、表空间名称不能包含@字符。 Serverless不支持多租户管理与资源隔离功能。 租户跨实例迁移： 开启多租户管理与资源隔离功能后，DRS迁移可以迁移所有租户下的数据，但DRS不会同步租户相关元数据，故租户信息不会被同步到目标端。如果需要迁移某个租户到另一个实例，需要遵循以下步骤： 目标端需要使用具备多租特性的实例，首先在目标端手动创建租户。 使用DRS数据同步功能创建库级同步任务（如果源端和目标端租户名有改动，则这里需要改动目标端库名）。 进行同步。 Binlog： 目前Binlog没有实现租户隔离，如果允许普通租户拉取Binlog会破坏租户间数据隔离，因此当前禁止普通租户下的用户拉取Binlog。 数据库代理： 因HTAP标准版和轻量版不支持带@字符的数据库，普通租户下的数据库迁移到该类HTAP引擎时会更改目标端库名，但数据库代理的自动行存/列存引流功能要求源端和目标端的库名一致，因此普通租户创建的数据库将无法使用数据库代理的自动行存/列存引流功能。 备份恢复： 恢复已打开过多租开关的多租实例数据到新实例，未开启多租开关下，新实例不支持创建带@的用户、数据库和表空间。 兼容性： 先开启后关闭多租开关，创建数据库、用户和表空间时，名称中不能包含@字符。 普通租户下，数据库名称最大长度由64降低为50，用户名称最大长度由32降低为20。 系统库mysql、sys暂不开放给普通租户。 普通租户下，系统库performance_schema里的表使用用户名或库名做条件查询时，需要使用模糊搜索。 系统租户的root用户可以kill其他用户的session；普通租户的用户，只能kill当前用户的session。 多租实例不支持全文索引。

使用限制 当前版本支持分区级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创建的新分区。可以通过重新执行事务来解决这个问题。

创建LIST DEFAULT HASH分区表 语法 CREATE TABLE [ schema. ]table_name table_definition PARTITION BY LIST [COLUMNS] (expr) SUBPARTITION BY ... (list_partition_definition[, ..., list_partition_definition], default_partition_definition ) 其中，default_partition_definition为： PARTITION partition_name DEFAULT [PARTITIONS number] 每个分区的定义也可以包含二级分区， 二级分区也支持使用LIST DEFAULT分区，定义如下： SUBPARTITION subpartition_name DEFAULT 表2 参数说明 参数名称 参数说明 table_name 要创建的表名称。 partition_name 只有一个DEFAULT分区时，表示分区名称。不可与其他分区表重复。 当有多个DEFAULT分区时，表示分区名称前缀。“partition_name+序号”表示分区名称。 subpartition_name 子分区名称。同一个表中不可重复，子分区最多只支持一个DEFAULT分区。 number DEFAULT分区按照哈希规则分成number个分区，通过number指定分区个数。PARTITIONS number是可选项，不指定时，则默认为一个DEFAULT分区。 示例 创建单个DEFAULT分区示例如下： CREATE TABLE list_default_tbl ( a INT, b INT ) PARTITION BY LIST (a) (PARTITION p0 VALUES IN (1,2,3,4,5), PARTITION p1 VALUES IN (6,7,8,9,10), PARTITION pd DEFAULT); 创建多个DEFAULT分区示例如下： CREATE TABLE list_default_hash ( a INT, b INT ) PARTITION BY LIST (a) (PARTITION p0 VALUES IN (1,2,3,4,5), PARTITION p1 VALUES IN (6,7,8,9,10), PARTITION pd DEFAULT PARTITIONS 3); 使用LIST COLUMNS示例如下： CREATE TABLE t_goods ( country VARCHAR(30), year VARCHAR(60), goods TEXT ) PARTITION BY LIST COLUMNS(country) ( PARTITION p1 VALUES IN ('China'), PARTITION p2 VALUES IN ('USA'), PARTITION p3 VALUES IN ('Asia'), PARTITION p3 VALUES IN ('India'), PARTITION p_deft DEFAULT PARTITIONS 5 ); 通过explain查看分区： EXPLAIN SELECT * FROM list_default_hash; 显示结果如下： +----+-------------+-------------------+-------------------+------+---------------+------+---------+------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------------------+-------------------+------+---------------+------+---------+------+------+----------+-------+ | 1 | SIMPLE | list_default_hash | p0,p1,pd0,pd1,pd2 | ALL | NULL | NULL | NULL | NULL | 1 | 100.00 | NULL | +----+-------------+-------------------+-------------------+------+---------------+------+---------+------+------+----------+-------+ 1 row in set (0.04 sec) 二级分区支持LIST DEFAULT类型，示例如下： CREATE TABLE test (a int, b int) PARTITION BY RANGE(a) SUBPARTITION BY LIST(b) ( PARTITION part0 VALUES LESS THAN (10) ( SUBPARTITION sub0 VALUES IN (1,2,3,4,5), SUBPARTITION sub1 DEFAULT), PARTITION part1 VALUES LESS THAN (20) ( SUBPARTITION sub2 VALUES IN (1,2,3,4,5), SUBPARTITION sub3 DEFAULT), PARTITION part2 VALUES LESS THAN (30) ( SUBPARTITION sub4 VALUES IN (1,2,3,4,5), SUBPARTITION sub5 DEFAULT)); 一级分区存在多个LIST DEFAULT HASH分区的情况下，仅支持HASH或KEY二级分区： CREATE TABLE list_default_hash_sub ( a INT, b INT ) PARTITION BY LIST (a) SUBPARTITION BY HASH (b) SUBPARTITIONS 20 (PARTITION p0 VALUES IN (1,2,3,4,5), PARTITION p1 VALUES IN (6,7,8,9,10), PARTITION pd DEFAULT PARTITIONS 3);

修改LIST DEFAULT HASH分区表 LIST DEFAULT HASH分区支持所有修改分区表的语法，包括ALTER TABLE ADD PARTITION、ALTER TABLE DROP PARTITION、ALTER TABLE REORGANIZE PARTITION、ALTER TABLE TRUNCATE PARTITION、ALTER TABLE EXCHANGE PARTITION、ALTER TABLE OPTIMIZE PARTITIONALTER TABLE REBUILD PARTITION、ALTER TABLE REPAIR PARTITION、ALTER TABLE ANALYZE PARTITION、ALTER TABLE CHECK PARTITION操作。除了ALTER TABLE ADD PARTITION，ALTER TABLE DROP PARTITION，ALTER TABLE REORGANIZE PARTITION有特殊的使用方法和限制，其他的语法同其他类型的分区表使用方法一样。 ALTER TABLE ADD PARTITION ADD DEFAULT PARTITION 对于没有DEFAULT分区的普通LIST分区表，通过ADD PARTITION增加DEFAULT分区，使之变成LIST DEFAULT HASH分区表。 ALTER TABLE table_name ADD PARTITION(default_partition_definition) 增加一个DEFAULT分区示例如下： CREATE TABLE list_tab ( a INT, b INT ) PARTITION BY LIST (a) (PARTITION p0 VALUES IN (1,2,3,4,5), PARTITION p1 VALUES IN (6,7,8,9,10) ); ALTER TABLE list_tab ADD PARTITION(PARTITION pd DEFAULT); 增加两个DEFAULT分区示例如下： CREATE TABLE list_tab ( a INT, b INT ) PARTITION BY LIST (a) (PARTITION p0 VALUES IN (1,2,3,4,5), PARTITION p1 VALUES IN (6,7,8,9,10) ); ALTER TABLE list_tab ADD PARTITION(PARTITION pd DEFAULT PARTITIONS 2); ADD LIST PARTITION LIST DEFAULT HASH分区表ALTER TABLE ADD PARTITION语法支持使用WITHOUT VALIDATION选项添加LIST分区。 ALTER TABLE table_name ADD PARTITION( list_partition_definition[, ..., list_partition_definition]) WITHOUT VALIDATION 新增一个LIST分区的示例如下： CREATE TABLE list_default_hash ( a INT, b INT ) PARTITION BY LIST (a) (PARTITION p0 VALUES IN (1,2,3,4,5), PARTITION p1 VALUES IN (6,7,8,9,10), PARTITION pd DEFAULT PARTITIONS 3); ALTER TABLE list_default_hash ADD PARTITION( PARTITION p2 VALUES IN (11,12,13) )WITHOUT VALIDATION; 执行后，list_default_hash表会增加一个LIST分区p2，p2中没有数据。 一旦使用了without validation添加list分区，需要您手动执行`ALTER TABLE .. REBUILD ALL`命令，重新分配数据。否则数据不会重新分配，满足新添加的分区定义的数据仍存放在DEFAULT分区中，在查询时候会把default分区全部标记，不会裁剪掉，会导致查询性能下降。建议您使用ALTER TABLE REORGANIZE PARTITION语法，从DEFAULT分区中分离部分数据，建立新的LIST分区。 ALTER TABLE DROP PARTITION DROP PARTITION操作时，只能一次性删除全部DEFAULT分区，不支持只删除部分DEFAULT分区。 执行DROP PARTITION操作，删除所有分区的示例如下： ALTER TABLE list_default_hash DROP PARTITION pd0,pd1,pd2; Query OK, 0 rows affected (0.33 sec) Records: 0 Duplicates: 0 Warnings: 0 单独删除部分DEFAULT分区时会报错。 ALTER TABLE list_default_hash DROP PARTITION pd0; 报错信息如下： ERROR 8078 (HY000): DROP PARTITION cannot be used on default partitions of LIST DEFAULT, except once dropping all default partitions ALTER TABLE REORGANIZE PARTITION REORGANIZE PARTITION操作时，只能一次性修改全部DEFAULT分区，不支持只修改部分DEFAULT分区。 使用REORGANIZE PARTITION操作可以改变DEFAULT分区的个数： ALTER TABLE list_default_hash REORGANIZE PARTITION pd0,pd1 INTO( PARTITION pd DEFAULT PARTITIONS 3); 执行后，DEFAULT分区的个数会由2个变成3个。 使用REORGANIZE PARTITION可以从DEFAULT分区中分离出一个LIST分区： ALTER TABLE list_default_hash REORGANIZE PARTITION pd0,pd1 INTO ( PARTITION p2 VALUES IN (20,21), PARTITION pd DEFAULT PARTITIONS 2); 执行后，list_default_hash分区表会增加一个LIST分区p2， p2中会有从DEFAULT分区中分离出来的符合VALUES IN (20,21)的数据。 使用REORGANIZE PARTITION可以合并一个LIST分区到DEFAULT分区 ALTER TABLE list_default_hash REORGANIZE PARTITION p2, pd0, pd1 INTO ( PARTITION pd DEFAULT PARTITIONS 2); 执行后，LIST分区p2会合并到DEFAULT分区里。 使用REORGANIZE PARTITION可以从DEFAULT分区中分离部分values放到LIST分区： ALTER TABLE list_default REORGANIZE partition p2, pd0, pd1 INTO ( PARTITION p2 VALUES IN (20,21,22,23,24), PARTITION pd DEFAULT PARTITIONS 4); 执行后，p2的定义由PARTITION p2 VALUES IN (20,21)变为PARTITION p2 VALUES IN (20,21,22,23,24)， 相应的数据也会从DEFAULT分区挪到p2。

参数说明 在参数配置页面通过设置参数rds_list_default_partition_enabled的值来启用或禁用LIST DEFAULT HASH功能。 表1 参数说明 参数名称 级别 说明 rds_list_default_partition_enabled Global LIST DEFAULT HASH功能控制开关。 取值范围如下： ON: 启用LIST DEFAULT HASH功能。 OFF: 关闭LIST DEFAULT HASH功能。

Statement Outline表介绍 GaussDB(for MySQL)内置了一个系统表（outline）保存Hint，系统启动时会自动创建该表，无需您手动创建。创建表的SQL语句如下： CREATE TABLE `mysql`.`outline` ( `Id` bigint(20) NOT NULL AUTO_INCREMENT, `Schema_name` varchar(64) COLLATE utf8_bin DEFAULT NULL, `Digest` varchar(64) COLLATE utf8_bin NOT NULL, `Digest_text` longtext COLLATE utf8_bin, `Type` enum('IGNORE INDEX','USE INDEX','FORCE INDEX','OPTIMIZER') CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL, `Scope` enum('','FOR JOIN','FOR ORDER BY','FOR GROUP BY') CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT '', `State` enum('N','Y') CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT 'Y', `Position` bigint(20) NOT NULL, `Hint` text COLLATE utf8_bin NOT NULL, PRIMARY KEY (`Id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0 COMMENT='Statement outline'

功能介绍 GaussDB(for MySQL)分区表完全兼容社区MySQL的语法和功能。同时，GaussDB(for MySQL)分区表相对于社区MySQL进行了功能增强，支持丰富的分区表类型及组合，使您可以更加便携、简单和高效的使用分区表。 GaussDB(for MySQL)兼容的社区MySQL分区表类型如下： HASH KEY RANGE LIST RANGE-HASH RANGE-KEY LIST-HASH LIST-KEY 组合分区由一级分区（主分区）和二级分区（子分区）组成。 GaussDB(for MySQL)组合分区功能支持的分区表类型如下： RANGE-RANGE RANGE-LIST LIST-RANGE LIST-LIST HASH-HASH HASH-KEY HASH-RANGE HASH-LIST KEY-KEY KEY-HASH KEY-RANGE KEY-LIST 父主题： 二级分区

什么是并行查询 云数据库 GaussDB(for MySQL)支持了并行执行的查询方式，用以降低分析型查询场景的处理时间，满足企业级应用对查询低时延的要求。并行查询的基本实现原理是将查询任务进行切分并分发到多个CPU核上进行计算，充分利用CPU的多核计算资源来缩短查询时间。并行查询的性能提升倍数理论上与CPU的核数正相关，也就是说并行度越高能够使用的CPU核数就越多，性能提升的倍数也就越高。 下图是使用CPU多核资源并行计算一个表的count(*)过程的基本原理：表数据进行切块后分发给多个核进行并行计算，每个核计算部分数据得到一个中间count(*)结果，并在最后阶段将所有中间结果进行聚合得到最终结果。具体如下： 图1 并行查询原理图

应用场景 并行查询适用于大部分SELECT语句，例如大表查询、多表连接查询、计算量较大的查询。对于非常短的查询，效果不太显著。 轻分析类业务 报表查询通常SQL复杂而且比较耗费时间，通过并行查询可以加速单次查询效率。 系统资源相对空闲 并行查询会使用更多的系统资源，只有当系统的CPU较多、IO负载不高、内存够大的时候，才可以充分使用并行查询来提高资源利用率和查询效率。 数据频繁查询 针对数据密集型查询，通过并行查询，可以提高查询处理执行效率，减少网络流量和计算节点的压力。

使用示例 假设使用sysbench的表，表内有1亿条数据。 图1 查看表 在该表的“k”字段创建索引。 如图2所示，采用社区默认单线程创建索引，耗时146.82s。 图2 单线程创建创建索引 通过设置innodb_rds_parallel_index_creation_threads= 4，启用4个线程创建索引。 从图3中可以看到创建索引耗时38.72s，与社区单线程相比速度提升了3.79倍。 图3 多线程创建索引 假设要修改主键索引，虽然指定了多线程，但是会收到一个告警，实际上只能通过单线程建索引。 图4 修改主键索引

约束与限制 内核版本为2.0.45.230900及以上版本支持使用该功能。 并行创建索引功能，目前支持的索引为Btree二级索引。 不支持主键索引、spatial index和fulltext index。如果一个并行创建索引的SQL语句包含主键索引，或者spatial index和fulltext index，客户端将会收到一个告警，提示该操作不支持并行创建索引，同时该语句会采用单线程创建索引的方式执行完成。假设在修改主键索引时，虽然指定了多线程，但是会收到一个告警，实际上只能通过单线程建索引。

只读延迟的计算 只读延迟是指在主节点更新数据后，在多少时间后能在只读节点得到这个最新数据。 只读节点读取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时刻的数据。

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

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

功能介绍 该特性默认打开，当表在创建索引的时候，通过查询INFORMATION_SCHEMA.INNODB_ALTER_TABLE_PROGRESS这个表的信息可以获取当前进度，表结构如下： 图1 表结构 THREAD_ID为线程ID。 QUERY是指客户端下发的创建index语句。 START_TIME为创建index命令下发时间。 ELAPSED_TIME是指已经用了多少时间。 ALTER_TABLE_PHASE是指当前到哪个阶段了。 WORK_COMPLETED是指当前已经完成的工作量。 WORK_ESTIMATED是指整个创建index流程一共多少工作量的估计值。 TIME_REQUIRED是预计还需要多长时间。 WORK_ESTIMATED和TIME_REQUIRED会随着index创建的进行，一直调整，所以不是并非线性变化。

使用示例 执行如下SQL查询目标表结构。 desc table_name; 例如： 查询表test_stage的结构。 desc test_stage； 图2 查看表结构 从上述表结构中可以看出，表test_stage中不存在二级索引。 执行如下SQL，为目标表的某一列增加索引。 ALTER TABLE table_name ADD INDEX idxa(field_name); 例如： 对test_stage表的a列增加索引。 ALTER TABLE test_stage ADD INDEX idxa(a); 执行如下SQL查询创建索引的进度。 SELECT QUERY, ALTER_TABLE_PHASE FROM INFORMATION_SCHEMA.INNODB_ALTER_TABLE_PROGRESS; 图3 查询创建索引的进度

什么是算子下推（NDP） NDP(Near Data Processing)是云数据库GaussDB(for MySQL)发布的旨在提高数据查询效率的计算下推的解决方案。针对数据密集型查询，将提取列、聚合运算、条件过滤等操作从计算节点向下推送给GaussDB(for MySQL)的分布式存储层的多个节点，并行执行。通过计算下推方法，提升了并行处理能力，减少网络流量和计算节点的压力，提高了查询处理执行效率。

工作原理 云数据库GaussDB(for MySQL)采用计算与存储分离的架构，以减少网络流量为主要架构准则，通过NDP设计将该准则应用到查询操作。没有NDP之前，查询处理需要将原始数据从存储节点全部传输到计算节点。通过NDP设计，查询中的I/O密集型和CPU密集型的大部分工作被下推到存储节点完成，仅将所需列及筛选后的行或聚合后的结果值回传给计算节点，使网络流量大幅减少。同时跨存储节点并行处理，使计算节点CPU使用率下降，提升了查询效率性能。 另外，NDP框架同GaussDB(for MySQL)并行查询进行融合，并进行了页面批量预取的设计，达成执行全流程并行，进一步提升查询执行效率。