华为云用户手册

原因分析 大部分情况下，distinct是可以转化成等价的group by语句。在MySQL中，distinct关键字的主要作用就是去重过滤。 distinct进行去重的原理是先进行分组操作，然后从每组数据中取一条返回给客户端，分组时有两种场景： distinct的字段全部包含于同一索引：该场景下MySQL直接使用索引对数据进行分组，然后从每组数据中取一条数据返回。 distinct字段未全部包含于索引：该场景下索引不能满足去重分组需要，会用到临时表（首先将满足条件的数据写入临时表中，然后在临时表中对数据进行分组，返回合适的数据）。因为使用临时表会带来额外的开销，所以一般情况下性能会较差。 综上，在使用distinct或group by的时候，尽量在合理的情况下设置可以包含所有依赖字段的索引，优化示例： 没有合适索引，导致需要用到临时表。 有合适的索引，不会使用临时表，直接走索引。

原因分析 表字段类型是TIMESTAMP类型， 关于timestamp字段：MySQL会把该字段插入的值从当前时区转换成UTC时间（世界标准时间）存储，查询时，又将其从UTC时间转化为当前时区时间返回 timestamp类型字段的时间范围：'1970-01-01 00:00:01' UTC -- '2038-01-19 03:14:07' UTC，详见官方文档： 使用如下命令，查看当前的时区： show variables like "%zone%"; 故障场景中使用的是utc+8时区，如下图，所以timestamp字段默认值需要加8小时才是有效范围，有效支持的范围是从1970-01-01 08:00:01开始；

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

原因分析 查看内存利用率监控指标，实例的内存使用率在16:30左右率突增，触发OOM后实例重启，内存使用率骤降。 图1 内存利用率 查看该时间段慢SQL数监控指标，确认该时间段慢SQL数量突增。 图2 慢SQL数 查看磁盘吞吐相关指标，发现磁盘此时有大量读写操作。 图3 磁盘吞吐 分析对应时间点的慢日志记录，该时间点有大量的多值批量插入语句，该插入方式会导致每个会话申请较多的SESSION级内存，并发高，很容易引起实例OOM。 图4 慢日志

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

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

场景描述 在搭建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)

修改库名和修改表名 对于库重命名和表重命名，TaurusDB与社区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; 父主题： 基本使用类

解决方案 方案1：可以在需要排序的字段上加上索引。如案例中，alter table ratings add index idx_category (category); 方案2：可以在排序语句的order by后面加入主键列。如案例中，select * from ratings order by category, id limit 2,2; 方案3：可以在TaurusDB控制台参数修改页面，开启参数“rds_force_stable_sort”。该参数开启后，将强制使用稳定排序算法，确保排序结果的稳定。 图1 设置参数rds_force_stable_sort

场景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。

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

mysqldump选项解析 表1 配置项说明 选项名称 说明 add-drop-table 每个数据表创建之前添加drop数据表语句。 events，E 导出事件。 routines，R 存储过程以及自定义函数。 flush-logs 开始导出之前刷新日志。 no-create-db，n 只导出数据，而不添加CREATE DATABASE语句。 add-drop-database 创建数据库之前添加drop数据库语句。 no-create-info，t 只导出数据，而不添加CREATE TABLE语句。 no-data，d 不导出任何数据，只导出数据库表结构。 set-gtid-purged=OFF 不导出gtid相关语句。 hex-blob 使用十六进制格式导出二进制字符串字段。

问题分析 查询确认后，发现消失的账号在mysql.user表中已经被删除，故控制台不再显示； 使用账号名和旧密码还能连接登录，说明使用的是delete from mysql.user方式删除用户。使用这种方式删除用户，需要执行flush privileges后，才会清理内存中相关数据，该用户才彻底不能登录。 使用delete from mysql.user方式删除用户，无法重新创建相应账户（报错ERROR 1396），原因是内存中相关数据仍然存在。

原因分析 查看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下降到正常水平，业务恢复。

解决方案 建议新上业务时，提前对关键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”。

场景描述 MySQL用户创建表失败，出现如下报错信息： Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

场景案例 假定max_allowed_packet参数大小为1073741824。 创建表。 CREATE TABLE IF NOT EXISTS zstest1 ( id int PRIMARY KEY not null, c_longtext LONGTEXT ); 向表中插入数据。 insert into zstest1 values(1, repeat('a', 1073741800)); insert into zstest1 values(2, repeat('a', 1073741800)); insert into zstest1 values(3, repeat('a', 1073741800)); insert into zstest1 values(4, repeat('a', 1073741800)); insert into zstest1 values(5, repeat('a', 1073741800)); insert into zstest1 values(6, repeat('a', 1073741800)); insert into zstest1 values(7, repeat('a', 1073741800)); insert into zstest1 values(8, repeat('a', 1073741800)); insert into zstest1 values(9, repeat('a', 1073741800)); insert into zstest1 values(10, repeat('a', 1073741800)); 删除数据。 delete from zstest1; 执行查询语句。 select id from zstest1; //执行缓慢

TaurusDB timeout相关参数简介 MySQL中有多种timeout参数，TaurusDB也将相关参数提供给用户设置，如下表： 表1 参数说明 参数名称 修改是否需要重启 参数含义 connect_timeout 否 控制客户端和MySQL服务端在建连接时，服务端等待三次握手成功的超时时间（秒），网络状态较差时，可以调大该参数。 innodb_flush_log_at_timeout 否 每N秒写入并刷新日志。当innodb_flush_log_at_trx_commit值为2时，此设置有效。 innodb_lock_wait_timeout 否 该变量控制innodb事务获取行锁等待的最长时间（秒），如果超过该时间还未获取到锁资源，则会返回执行失败。 parallel_queue_timeout 否 请求并行执行的查询的等待时间。如果超过该等待时间后，系统中并行执行的线程数仍然大于parallel_max_threads，则不再等待而进入单线程执行。 lock_wait_timeout 否 试图获得元数据锁的超时时间（秒）。 net_read_timeout 否 中止读数据之前从一个连接等待更多数据的秒数。 net_write_timeout 否 中止写之前等待一个块被写入连接的秒数。 interactive_timeout 否 服务器在关闭交互式连接之前等待活动的秒数。 wait_timeout 否 服务器关闭连接之前等待非交互式连接活动的秒数。 父主题： 参数类

解决方案 如果客户端使用了和数据库不同的字符集，需要调整客户端配置，使用相同的字符集连接数据库，或者在连上数据库后显式设置成对应的字符集，即可正常查询。 显式设置字符集的方法如下： set collation_connection = utf8mb4_general_ci; 其中“utf8mb4_general_ci”为需要设置的字符集和排序规则。 当出现如下信息，表示字符集设置成功。 Query OK, 0 rows affected (0.00 sec)

原因分析 同一条SQL语句在数据库中执行第一次和第二次可能会性能差异巨大，这是由数据库的buffer_pool机制决定的： 第一次执行时，数据在磁盘上，称之为冷数据，读取需要一定的耗时。 读取完，数据会被存放于内存的buffer_pool中，称为热数据，读取迅速；对于热数据的访问速度极大地超过冷数据，所以当数据是热数据时，SQL语句的执行速度会远快于冷数据。 该场景中，源端数据库中常用的数据一般是热数据，所以访问时速度极快。当数据迁移到云上TaurusDB时，第一次执行同样的SQL语句，很可能是冷数据，就会访问较慢，但再次访问速度就会得到提升。

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

默认选择方式 在创建数据库时，如果未显式指定库的字符集和字符序，则库的字符集和字符序采用character_set_server和collation_server参数的值；如果显式指定，则使用指定的字符集和字符序。 在创建数据表时，如果未显式指定表的字符集和字符序，则表默认字符集和字符序使用所在数据库的字符集和字符序；如果显式指定，则使用指定的字符集和字符序。 在创建数据表时，如果未显式指定字段的字符集和字符序，则字段使用所在表的字符集和字符序；如果显式指定，则使用指定的字符集和字符序。 示例1：不显式指定字符集、字符序的情况下创建数据库和数据表。 示例2：显式指定库的字符集、字符序的情况下创建数据库。 示例3：显式指定表的字符集、字符序的情况下创建数据表。 示例4：显式指定字段的字符集、字符序的情况下创建数据表。

原因分析 经过排查，是因为参数“sql_mode”设置了NO_FIELD_OPTIONS属性。 sql_mode相关属性介绍： NO_FIELD_OPTIONS：不要在SHOW CREATE TABLE的输出中打印MySQL专用列选项。 NO_KEY_OPTIONS：不要在SHOW CREATE TABLE的输出中打印MySQL专用索引选项。 NO_TABLE_OPTIONS：不要在SHOW CREATE TABLE的输出中打印MySQL专用表选项（例如ENGINE）。

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

语法 创建一个或多个RANGE-RANGE分区表，其中每个分区可能有一个或一个以上的RANGE类型的子分区。 CREATE TABLE ... PARTITION BY RANGE {(expr) | COLUMNS(column_list)} SUBPARTITION BY RANGE {(expr) | COLUMNS(column_list)}[(partition_definition [, partition_definition] ...)]; 其中，partition_definition为： PARTITION partition_name VALUES LESS THAN {(value | MAXVALUE | value_list) | MAXVALUE}[(subpartition_definition [, subpartition_definition] ...)] subpartition_definition为： SUBPARTITION subpartition_name VALUES LESS THAN {value | value_list | MAXVALUE} 表1 参数说明 参数名称 描述 expr 分区字段表达式。目前只支持INT类型，不支持字符类型。 column_list RANGE COLUMNS的情况下使用。分区字段列表，不支持表达式，可以支持多列。 value 分区边界值。 value_list RANGE COLUMNS的情况下使用，多个字段的边界值。 MAXVALUE 最大值。 partition_name 分区名称，同一个表中不可重复。 subpartition_name 子分区名称， 同一个表中不可重复。

使用示例 RANGE-RANGE类型的使用示例 CREATE TABLE tbl_range_range (col1 INT, col2 INT, col3 varchar(20))PARTITION BY RANGE(col1)SUBPARTITION BY RANGE(col2)( PARTITION p0 VALUES LESS THAN (1000) ( SUBPARTITION s0 VALUES LESS THAN(100), SUBPARTITION s1 VALUES LESS THAN(MAXVALUE) ), PARTITION p1 VALUES LESS THAN (2000) ( SUBPARTITION s2 VALUES LESS THAN(100), SUBPARTITION s3 VALUES LESS THAN(200) ), PARTITION p2 VALUES LESS THAN (MAXVALUE) ( SUBPARTITION s4 VALUES LESS THAN(200), SUBPARTITION s5 VALUES LESS THAN(400) )); RANGE COLUMNS-RANGE类型的使用示例 CREATE TABLE tbl_range_col_range (col1 INT, col2 INT, col3 INT)PARTITION BY RANGE COLUMNS(col1, col2)SUBPARTITION BY RANGE(col3)( PARTITION p1 VALUES LESS THAN(1000, MAXVALUE)( SUBPARTITION s0 VALUES LESS THAN(100), SUBPARTITION s1 VALUES LESS THAN(MAXVALUE) ), PARTITION p2 VALUES LESS THAN(2000, MAXVALUE)( SUBPARTITION s2 VALUES LESS THAN(100), SUBPARTITION s3 VALUES LESS THAN(200) ), PARTITION p3 VALUES LESS THAN(MAXVALUE, MAXVALUE)( SUBPARTITION s4 VALUES LESS THAN(200), SUBPARTITION s5 VALUES LESS THAN(400) ));

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

使用示例 表回收站功能提供以下命令用于操作回收站中暂存的表。 查看回收站中暂存的表 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('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');

使用示例 执行如下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 查询创建索引的进度

功能介绍 该特性默认打开，当表在创建索引的时候，通过查询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创建的进行，一直调整，所以不是并非线性变化。