华为云用户手册

解决方案 针对多值插入方式引起的OOM，建议减少单次插入数据量，分多次插入，且及时断开重连会话以释放内存。可执行show full processlist查看是否有明显占用内存高的会话。 合理设置SESSION级内存参数大小，可大体根据全局内存+会话级内存*最大会话数来预估可能最大的内存。注意开启“performance_schema”也会带来内存开销。 升级实例规格，将内存利用率维持在合理范围，防止业务突增导致实例OOM。

TaurusDB内存说明 TaurusDB的内存大体可以分为GLOBAL级的共享内存和SESSION级的私有内存两部分： 共享内存是实例创建时根据参数值分配的内存空间，并且是所有连接共享的。 私有内存用于每个连接到TaurusDB服务器时才分配各自的缓存，且只有断开连接才会释放。 低效的SQL语句或数据库参数设置不当都可能会导致内存利用率升高，遇到突发业务高峰时，可能会导致云数据库内存OOM（Out Of Memory）。

通过命令查看存储容量 连接TaurusDB数据库后，执行如下命令查看存储容量。 show spaceusage; 上述命令查询到的存储容量值等于表数据、表预分配空间、分区预分配空间、Binlog、Redolog和undo space之和，详情请参见表1。 information_schema信息不是实时刷新的，查询之前可以先执行如下命令进行刷新： set information_schema_stats_expiry = 0; 表1 存储容量说明 条目 查看方式 说明 表数据 select sum(data_length+index_length+data_free) from information_schema.tables; 传统MySQL的容量计算方式，该语句依赖统计数据的精准度，在统计数据未更新时可能会有偏差。 表预分配空间 select count(*) from information_schema.tables; 每张表会预分配4MB空间，该语句查询出表的数量乘以4MB就是总的表预分配空间。 分区预分配空间 select count(*) from INFORMATION_SCHEMA.PARTITIONS where PARTITION_NAME is not null; 每个分区会预分配4MB空间，该语句查询出分区的数量乘以4MB就是总的分区预分配空间。 Binlog show binary logs; 将所有binlog的文件大小相加。 Redolog show lsninfo; flushed_to_disk_lsn- truncate_lsn undo space select sum(INITIAL_SIZE) as undo_space from information_schema.files where file_type='UNDO LOG '; undo空间。

解决方案 对于存在大量新建连接，建议调大threadpool_oversubscribe增加线程总数。 减少线程重复创建与销毁部分的开销，提高性能，同时它也限制了MySQL的runing线程数，关键时刻可以保护系统，防止雪崩。 正常情况下，线程池适用于大量短连接的场景，如果客户是长连接，并且连接数量不多（客户端使用了连接池等情况），线程池的作用不大，此时调整threadpool_size和threadpool_oversubscribe两个参数扩大线程总数，或者直接关闭线程池。

原因分析 查看TaurusDB的错误日志，观察是否有如下信息：connection xxx is established slowly。示例： 有上述日志，说明存在某些连接超过一定时间仍未被MySQL处理，客户端的超时时间大于该时间，就会报错。 进一步查看线程池配置（默认开启），可以在控制台查看。 可以看出，threadpool_size为1，threadpool_stall_limit为500ms，threadpool_oversubscribe为3，线程池处理连接等待的时间主要与上述3个参数相关： 当线程池所有线程在忙碌，线程池中的调度线程会每隔500ms（threadpool_stall_limit）创建一个新线程，所以此时，每个线程组平均每500ms才能处理一个新的连接。如果队列太长，很可能导致客户端超时； 所有线程都在忙碌是指，工作线程达到线程池总线程数，在大量建立连接时，总线程数计算方法：threadpool_size*(threadpool_oversubscribe+1))

原因分析 场景1：DRS全量迁移阶段并行迁移导致 原因：DRS在全量迁移阶段，为了保证迁移性能和传输的稳定性，采用了行级并行的迁移方式。当源端数据紧凑情况下，通过DRS迁移到云上TaurusDB后，可能会出现数据膨胀现象，使得磁盘空间使用远大于源端。 场景2：大量删除操作后在表空间留下碎片所致 原因：当删除数据时，MySQL并不会回收被删除数据占据的存储空间，而只做标记删除，尝试供后续复用，等新的数据来填补相应空间，如果一时半会，没有数据来填补这些空间，就造成了表空间膨胀，形成大量碎片。 可以通过如下SQL语句，查询某个表详细信息，DATA_FREE字段表示表空间碎片大小： 更新统计信息 analyze table db_name.table_name; 查看碎片大小 select * from information_schema.tables where table_schema='db_name' and table_name = 'table_name'\G;

解决方案 TaurusDB是兼容社区8.0以上版本的，需要使用8.0及以上版本的mysql client或数据库驱动。 SSL(Secure Socket Layer：安全套接字层)使用 数据加密 、身份校验和消息完整性校验，为连接提供安全性保证。 SSL提供的功能主要包含： 加密数据传输：利用对称密钥算法对传输的数据进行加密。 身份校验：基于证书使用数字签名的方法对客户端与服务器进行身份验证。 消息完整性校验：消息传输过程中使用MAC算法来检验消息的完整性。 注意 当服务端的SSL开启时，客户端的身份验证是可选的，即：即使服务端开启了SSL，客户端也可以不通过SSL的方式连接服务端，此时也可以正常通信，只是数据不会被加密。 如果不是通过SSL的方式，那么其在网络中的传输数据会以明文进行，存在安全隐患。 TaurusDB数据库服务端会默认开启服务端会默认开启SSL（如需关闭可参考：设置SSL数据加密），客户业务使用时可以在客户端自行选择是否使用SSL。 使用mysql client连接时使用SSL的方式可参考：通过客户端连接TaurusDB。 使用JDBC连接时使用SSL的方式可参考：通过JDBC连接MySQL数据库。

场景描述 在搭建canal环境，使用指定用户从TaurusDB获取Binlog时，启动canal经常会报如下错误：'show master status' has an error! Access denied: you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation 完整报错信息如下： 2021-01-10 23:58:32.964 [destination = evoicedc , address = /dbus-mysql:3306 , EventParser] ERROR com.alibaba.ot ter.canal.common.alarm.LogAlarmHandler - destination:evoicedc[com.alibaba.otter.canal.parse.exception.CanalParseEx ception: command : 'show master status' has an error! Caused by: java.io.IOException: ErrorPacket [errorNumber=1227, fieldCount=-1, message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, sqlState=42000, sqlStateMarker=#] with command: show master status at com.alibaba.otter.canal.parse.driver.mysql.MysqlQueryExecutor.query(MysqlQueryExecutor.java:61)

场景2 连接和QPS升高导致CPU上升 问题原因：业务请求增高导致实例CPU升高，需要从业务侧分析请求变化的原因。 排查思路： 查看QPS、当前活跃连接数、数据库总连接数、CPU使用率监控指标是否吻合。 QPS的含义是每秒查询数，QPS和当前活跃连接数同时上升，且QPS和CPU使用率曲线变化吻合，可以确定是业务请求增高导致CPU上升，如下图： 该场景下，SQL语句一般比较简单，执行效率也高，数据库侧优化余地小，需要从业务源头优化。 解决方案： 单纯的QPS高导致CPU使用率过高，往往出现在实例规格较小的情况下，建议升级实例CPU规格。 优化慢查询，优化方法参照场景1 慢查询导致CPU升高的解决方案。若优化慢查询后效果不明显，建议升级实例CPU规格。 对于数据量大的表，建议通过分库分表减小单次查询访问的数据量。 使用数据库代理+只读节点架构，实现读写分离。只读节点专门负责查询，减轻主库压力，提升数据库吞吐能力，详见读写分离简介。

场景1 慢查询导致CPU升高 问题原因：大量慢SQL导致实例CPU升高，需要优化相应的慢SQL。 排查思路： 查看CPU使用率和慢日志个数统计监控指标。 如果慢日志个数很多，且与CPU曲线吻合，可以确定是慢SQL导致CPU升高。 如果慢日志个数不多，但与CPU使用率基本一致，进一步查看行读取速率指标是否与CPU曲线吻合。 如果吻合，说明是少量慢SQL访问大量行数据导致CPU升高：由于这些慢SQL查询执行效率低，为获得预期的结果需要访问大量的数据导致平均IO高，因此在QPS并不高的情况下（例如网站访问量不大），也会导致实例的CPU使用率偏高。 解决方案： 根据CPU使用率过高的时间点，查看对应时间段的慢日志信息。 重点关注扫描行数、返回结果行数超过百万级别的慢查询，以及锁等待时间长的慢查询。 慢查询用户可自行分析，或使用数据管理服务(DAS)的SQL诊断工具对慢查询语句进行诊断。 使用数据库代理+只读节点架构，实现读写分离。只读节点专门负责查询，减轻主库压力，提升数据库吞吐能力，详见读写分离简介。 通过分析数据库执行中的会话来定位执行效率低的SQL。 连接数据库。 执行show full processlist;。 分析执行时间长、运行状态为Sending data、Copying to tmp table、Copying to tmp table on disk、Sorting result、Using filesort的会话，均可能存在性能问题，通过会话来分析其正在执行的SQL。

解决方案 建议新上业务时，提前对关键SQL通过EXPLAIN、SQL诊断等工具进行执行计划分析，根据优化建议添加索引，避免全表扫描。 业务量突增的高并发造成CPU占用率高，可以考虑升级实例规格或使用独享型资源避免出现CPU资源争抢，或者创建只读实例进行读写分离减轻主实例负载。 通过show processlist查看当前会话信息来辅助定位：运行状态为Sending data、Copying to tmp table、Copying to tmp table on disk、Sorting result、Using filesort的查询会话可能均包含性能问题。 应急场景可以借助SQL限流以及KILL会话功能来临时kill规避“烂SQL”。

原因分析 查看CPU使用率监控指标，发现在16:08分左右实例的CPU使用率开始飙升到100%，且一直持续在高位线。 图1 CPU使用率 查看QPS、慢SQL数以及活跃连接数监控指标，发现在16:08分左右QPS突增，活跃连接数上涨，最终业务侧有较多的慢SQL产生。 图2 QPS 图3 活跃连接数 图4 慢SQL数 分析业务类型，查看16:08分前左右InnoDB的逻辑读速率有突增，且与慢SQL的速率趋势相似。 图5 InnoDB逻辑读速率 登录实例，查看实话会话，发现大量会话在执行SELECT COUNT(*)。 EXPLAIN确认该SQL的执行计划，发现走全表扫描且单条扫描行数在35万+，其并未走索引。 进一步查看该表的表结构，发现该表仅对字段“is_deleted”添加了一个索引“IDX_XX_USERID”，因此上述查询无索引可选。建议业务侧给字段“idx_user_id”新增索引后，实例在16:37分左右CPU下降到正常水平，业务恢复。

场景描述 canal解析Binlog出现错误，导致拉取Binlog中断，错误信息如下： com.alibaba.otter.canal.parse.exception.CanalParseException: java.lang.NumberFormatException:- Caused by: java.lang.NumberFormatException: - at com.alibaba.fastsql.sql.parser.Lexer.integerValue(Lexer.java:2454)

原因分析 检查 GaussDB (for MySQL)的参数“binlog_rows_query_log_events”的值是否设置为1或ON。 目前canal只能支持ROW格式的Binlog增量订阅。 当GaussDB(for MySQL)的参数“binlog_rows_query_log_events”的值设置为1或ON时，会在Binlog中产生Rows_query类型的event，此类event非ROW格式，一些场景下，会导致canal出现blank topic问题，引发Binlog解析失败。

修改库名和修改表名 对于库重命名和表重命名，GaussDB(for MySQL)与社区MySQL的用法是相同的。 支持修改表名：rename table a to b; 注意，该语句是可以跨库执行的，比如：rename table da.ta to db.ta;是将ta表从da库移动到db库。 不支持修改库名，如果有修改库名的需求，可以先创建新的库名，然后借助rename table的跨库执行将所有表从原库移动到新库，然后删除原库。语句示例： # 进入原库 use ta; # 列出原库的所有表名 Show tables; # 查看原库的创建语句 Show create database ta; # 使用原库的创建语句创建新库(只改库名，其他参数照抄，这样能尽量保证新库与原库的各类参数相同) create database tb； # 将原库所有表移动至新库 rename table da.ta to db.ta; rename table da.tb to db.tb; rename table da.tc to db.tc; … # 删除原库 Drop database ta; 父主题： 基本使用类

2.0.31.220700 表18 2.0.31.220700版本说明 日期 特性描述 2022-08-12 新特性及性能优化 支持SQL限流。 新增FasterDDL并行数限制。 支持Faster DDL的所有ROW格式。 扩展全量SQL字段。 优化流量控制。 支持ALTER TABLE快速超时。 支持Query plan cache。 备机统计信息优化。 问题修复 修复主机rename partition-table之后备机crash的问题。 修改sql tracer的默认buffer size。 修复备机truncate lsn落后很多情况下备机拉起失败的问题。 修复含有多个相同范围的SQL查询导致的执行计划错误的问题。 修复空账户导致的crash的问题。 修复drop database可能导致的crash的问题。

2.0.28.15 表11 2.0.28.15版本说明 日期 特性描述 2023-01-11 新特性 支持SQL限流。 读流控优化。 主备执行计划一致优化。 slice异步预创建。 问题修复 修复系统变量INNODB_VALIDATE_TABLESPACE_PATHS关闭情况下undo space truncate的时候出现的crash问题。 修复查询information_schema.innodb_trx较慢问题。 修复查询结果不一致的问题：left joins没有转化为inner joins。 修复优化子查询的过程中导致的crash问题。 修复并发instantDDL和DML场景下未按实际获取instant字段值的问题。 修复当load有FTS索引的两个INNODB表时可能导致OOM的问题。 修复更新百万级别的表的数据字典可能导致OOM的问题。

2.0.42.230600 表6 2.0.42.230600内核版本说明 日期 特性描述 2023-08-31 新增功能和性能优化： 优化全量与增量备份放到备库进行，减少主机内存/CPU占用。 优化UNDO损坏场景的快速定位：启动undo损坏时，明确打印出undo损坏和对应表名称。 优化备机查询性能劣后于主库问题。 优化in-list转临时表。 NDP特性规模商用。 用Statement Outline方法稳定执行计划。 PQ特性支持Round函数。 问题修复： 修复快速排序和优先级队列排序算法不稳定导致ORDER BY LIMIT与ORDER LIMIT结果集有重合的问题。 修复PQ语句极小概率情况返回错误结果的问题。 修复部分场景PREPARE语句执行报错的问题。 修复部分场景UNION查询上的PQ断言错误的问题。 修复实例主节点INSERT大数据量的时候只读升主，升主成功后用全文索引查询的结果不准确的问题。 修复备机使用general_log和slow_log表打印warning日志的问题。 修复部分场景设置锁等待时间参数innodb_lock_wait_timeout后，实际超时等待时间不一致的问题。 修复只读升主过程中，小概率出现Failed to find page in slice manager导致升主失败的问题。 修复salsql日志pwal扫描进度percentage值大于100%的问题。 修复执行sqlsmith工具, 查询语句在explain阶段偶现mysqld coredump。 修复SELECT DISTINCT + CAST函数转换datetime类型为float类型时，结果不正确的问题。

2.0.39.230300 表7 2.0.39.230300版本说明 日期 特性描述 2023-05-11 新特性及优化： 支持小规格实例。 备机DDL失效方案优化。 SALSQL使用空间容量计算优化。 支持对单个SQL语句使用资源进行限制。 支持admin port和local socket使用per thread。 pwalScanner内存优化。 支持修改default_collation_for_utf8mb4参数。 支持大事务检测能力。 支持Kill idle transactions。 优化增量恢复速度。 新增数据库描述和账号描述。 支持buffer pool resize加速。 问题修复： 修复Ptrc可能会导致Nestedloop join的结果不一致问题。 修复使用windows函数进行排序的子查询可能会导致crash问题。 修复使用rewrites view时，如果评估可能会把left joins转化为inner joins问题。 修复指定过滤条件的decimal类型的数据不返回结果问题。 修复内存非对齐问题。 修复全量日志中记录scan_row不准确问题。

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.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分布不均匀以及无法全部枚举的场景。 问题修复： 优化表级恢复性能。 优化大规格实例高并发场景备机的执行性能。

2.0.54.240900 表1 2.0.54.240900内核版本说明 日期 特性描述 2024-10-18 新增功能和性能优化： 分区级MDL锁：在MySQL社区版中，分区表的数据访问操作（DML）和分区维护操作（DDL）会互相阻塞，这意味着分区维护只能在业务低峰期进行。本版本实现了分区级别的MDL锁，使得分区表的锁粒度从表级降低到了分区级，不同分区上的DML和特定DDL（如增加和删除分区）在MDL锁上不会相互阻塞，从而大大提升分区间操作的并发性。 表回收站：启用此功能开关后，符合条件的DROP TABLE命令不会直接删除指定表，而是将表暂时存放到回收站中，达到最大保存时间后，后台会自动删除。回收站功能支持修改被删除表在回收站中的保留时间，您也可以随时将表从回收站中恢复或彻底删除。 问题修复： 优化资源抢占场景下，各租户的CPU资源不会严格按照配置的比例分配问题。 优化Statement Outline功能，支持视图，支持explain analyze语句。

2.0.51.240300 表3 2.0.51.240300内核版本说明 日期 特性描述 2024-03-30 新增功能和性能优化： 支持高性能全局一致性，在较低的性能损耗下，提供集群维度的强一致性读能力。 新增show binary logs no block语法，优化在show binary logs过程中对事务提交的阻塞情况。 提供undo truncate能力，优化大量写入场景导致undo空间膨胀的问题。 提高全量恢复的并行度，优化备份恢复效率。 问题修复： 修复一批window function查询结果不准确或异常错误的问题。 修复在打开plan cache后反复执行一类prepare statement，数据库节点崩溃的问题。 修复在先后执行的存储过程中，由于字符集不一致导致的报错问题。 修复一类开启PQ后进行磁盘hash join，查询结果不符合预期的问题。 修复一类查询含有group by临时表字段时，报错主键重复的问题。

2.0.48.231200 表4 2.0.48.231200内核版本说明 日期 特性描述 2024-01-30 新增功能和性能优化： 组合分区能力增强：在社区MySQL的RANGE-HASH、LIST-HASH两类组合分区能力基础上，增加了RANGE-RANGE、RANGE-LIST、LIST-RANGE、LIST-LIST、HASH-HASH、HASH-KEY、HASH-RANGE、HASH-LIST、KEY-HASH、KEY-KEY、KEY-RANGE、KEY-LIST的组合分区能力。 向前兼容MySQL 5.7 GROUP BY场景隐式/显式排序。 向前兼容MySQL 5.7 max_length_for_sort_data判据，优化特定场景文件排序性能。 优化因执行计划选错导致访问information_schema下视图较慢的问题。 PQ支持EXIST子查询。 优化库表或实例按时间点恢复性能。 问题修复： OPENSSL版本升级。 修复time_zone参数默认值SYSTEM会导致部分场景SQL并行执行效率降低的问题。 修复一类条件部分下推到物化derived table时，SQL查询结果不准确的问题。 修复部分场景磁盘hash join开启PQ后性能劣化的问题。 修复控制台赋予用户数据库权限后，通过非控制台的方式删除此数据库，权限页面未更新的问题。

2.0.28.16 表10 2.0.28.16版本说明 日期 特性描述 2023-03-14 新特性： 优化主备时延。 修复问题： 修复prepare statement中使用json相关函数处理错误问题。 修复指定过滤条件查询结果不返回的问题; 修复WINDOWS函数生成磁盘临时表后，出现空指针异常问题。 修复windows functions空指针使用导致的crash问题。 修复prepared statements执行失败的问题。

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回退的问题。 修复备机性能异常问题。

租户管理 创建租户时，需要绑定已经创建的资源配置（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;

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