华为云用户手册

原因分析 场景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

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

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

场景描述 在搭建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下降到正常水平，业务恢复。

场景描述 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; //执行缓慢

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

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负载不高、内存够大的时候，才可以充分使用并行查询来提高资源利用率和查询效率。 数据频繁查询 针对数据密集型查询，通过并行查询，可以提高查询处理执行效率，减少网络流量和计算节点的压力。

功能介绍 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 父主题： 二级分区

使用示例 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) ));

语法 创建一个或多个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 子分区名称， 同一个表中不可重复。

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

语法 创建一个或多个HASH-HASH分区表，其中每个分区可能有一个或一个以上的子分区。 CREATE TABLE [ schema. ]table_name table_definition PARTITION BY [LINEAR] HASH(expr) [PARTITIONS num] SUBPARTITION BY [LINEAR] HASH(expr) [SUBPARTITIONS sub_num] [partition_definition [, partition_definition] ...]; 其中，partition_definition为： PARTITION partition_name (subpartition_definition [, subpartition_definition] ...) subpartition_definition为： SUBPARTITION subpartition_name 表1 参数说明 参数名称 描述 table_name 要创建的表名称。 expr 分区字段表达式，目前只支持INT类型，不支持字符类型。 num 用于分区是HASH或者KEY类型的分区表，来指定分区个数。 sub_num 用于二级分区是HASH或者KEY类型的分区表，来指定单个分区的子分区的个数。 partition_name 分区名称，同一个表中不可重复。 subpartition_name 子分区名称， 同一个表中不可重复。

功能介绍 该特性默认打开，当表在创建索引的时候，通过查询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 查询创建索引的进度

创建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_hashREORGANIZE PARTITION pd0,pd1INTO( PARTITION pd DEFAULT PARTITIONS 3); 执行后，DEFAULT分区的个数会由2个变成3个。 使用REORGANIZE PARTITION可以从DEFAULT分区中分离出一个LIST分区： ALTER TABLE list_default_hashREORGANIZE PARTITION pd0,pd1INTO ( 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_hashREORGANIZE PARTITION p2, pd0, pd1INTO ( PARTITION pd DEFAULT PARTITIONS 2); 执行后，LIST分区p2会合并到DEFAULT分区里。 使用REORGANIZE PARTITION可以从DEFAULT分区中分离部分values放到LIST分区： ALTER TABLE list_defaultREORGANIZE partition p2, pd0, pd1INTO ( 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。