摘要：云服务环境下，如何解决客户基于大量数据创立索引的性能问题，成为云服务厂商的一个挑战。华为云GaussDB(for MySQL)通过引入并行创立索引技术，很好地解决了批量索引创立和长期增加索引等性能瓶颈问题，帮忙用户更快建设好索引。想要进一步理解疾速创立索引的秘诀，请不要错过本文。
本文分享自华为云社区《GaussDB(for MySQL)如何疾速创立索引？华为云数据库资深架构师为您揭秘》，作者：华为云数据库资深架构师苏斌。
苏斌，华为云数据库资深架构师，领有16年数据库内核研发教训，之前作为MySQL官网InnoDB团队次要研发人员，参加和主导了多个重要个性的开发和公布。目前在华为公司负责和参加华为云RDS次要产品RDS for MySQL和GaussDB(for MySQL)内核性能的设计和研发。
导读
云服务环境下，如何解决客户基于大量数据创立索引的性能问题，成为云服务厂商的一个挑战。华为云GaussDB(for MySQL)通过引入并行创立索引技术，很好地解决了批量索引创立和长期增加索引等性能瓶颈问题，帮忙用户更快建设好索引。想要进一步理解疾速创立索引的秘诀，请不要错过本文。
对于MySQL索引
咱们都晓得，数据库应用索引技术放慢数据的查问。MySQL数据库也反对若干种索引构造进步查问的性能（参见MySQL文档：https://dev.mysql.com/doc/ref...），其中应用最宽泛的是B+tree索引，因为B+tree索引在查问和批改的性能之间有很好的均衡，同时其存储和保护的代价也是比拟优的。
MySQL的表自身由聚簇索引（必须是B+tree索引）示意，再加上若干个二级索引，包含B+tree索引，独特组成一个MySQL的独立表，能够说MySQL的表是由一组索引独特组成的。咱们都晓得索引是一把双刃剑，充沛的索引能够更好地晋升能够适配的查问的性能，然而须要保护这些索引使得其和数据同步，所以在数据批改操作阶段，更多的索引也会带来更高的开销。索引创立与否的衡量通常是动静的，用户不肯定能做到在表定义之初就晓得须要建设哪些索引，须要随着业务的倒退变动而调整索引，这也带来了动静索引创立的一些问题。
MySQL的索引创立逻辑
咱们先看一下MySQL索引创立的逻辑。首先，MySQL索引的创立能够应用两种不同的DDL（Data Definition Language: 数据定义语言）算法来实现。第一种是COPY算法，它十分低效，就是在两个表之间进行数据拷贝，来实现表构造相干的批改，尤其是它要求加表锁，当初根本不应用了。第二种是INPLACE算法，该算法不要求加锁，因而很多DDL操作是不阻塞DML（Data Manipulation Language: 数据操纵语句）操作的，比方创立索引。该算法具体的实现在存储引擎层面实现，能够进行更多的优化。实际上DDL语句还有一种INSTANT算法，然而它无奈反对创立索引操作，这里不开展介绍。
对于INPLACE算法，在5.7版本之前，是采纳索引记录一直地向建好的空索引插入的形式。因为插入的数据的无序性，该办法导致了显著的性能问题和潜在的空间节约。在5.7版本当前，MySQL优化了建索引步骤，将其改良为对已排序的索引记录进行自底向上批量插入并且紧凑拼装的创立形式，如果有多个索引要创立，会独自对每个索引执行雷同的算法。新的算法会经验读取数据、排序数据和创立索引这几个次要步骤。
总体而言，创立索引这类DDL操作，会比一般的DML等操作要费时，而该类DDL耗时会导致用户在持续动静增加索引减速查问的时候，须要期待很长的工夫，极大影响业务；而且用户的MySQL实例开启了Binlog复制，耗时的DDL操作容易引起备库的长时间落后。
MySQL的创立索引流程图
云化场景下索引创立的问题
随着越来越多用户把数据托管在云服务上，以及用户数据量的一直增长，前述的动静增加索引导致的问题十分影响用户体验。同时客户的单表数据逐步达到几TB甚至几十TB，客户对创立索引太慢所带来的性能问题的埋怨越来越多，尤其是创立索引周期如果太长，咱们可能很难找到一段适合的业务低峰期来动态创建索引，防止业务的稳定。因而，如何在云服务环境下，解决客户基于大量数据创立索引的性能问题，成为云服务厂商的一个挑战。
在云化场景下，还有一个次要场景对客户的体验十分重要。咱们晓得客户的业务要迁徙上云，须要对数据进行大规模的迁徙（华为云提供了数据复制服务DRS工具反对各类数据迁徙场景），数据迁徙比拟高效的形式为：
- 逻辑导出源端数据
- 在指标端建表（留神，表不含二级索引）
- 将源端导出的数据插入到指标端
- 对指标端的表建设二级索引
如果波及动态数据同步，相干步骤会更简单一些，因为和该主题无关，这里不开展。以上步骤中，须要重点留神的是步骤2和4，在指标端创立表的时候先不创立二级索引。这个优化对性能影响很大，尤其是一个表有很多二级索引的场景。咱们晓得Btree索引的插入如果是有序的，对插入性能和后果的空间利用率是最好的，因为Btree索引的决裂会在插入区域的尾部产生，同时因为决裂算法的优化，决裂产生的页面填充率会比拟高；相同地，如果是随机插入，尤其是并发地随机插入，很容易导致Btree索引在不同的节点进行决裂，并且决裂后的页面填充率都处于一个半满的状态，导致Btree最终的一个收缩。
有了这个背景之后，咱们就容易了解下面的问题，插入表数据的时候，咱们屏蔽了二级索引，等所有数据都筹备好了，再采纳批量建设索引的形式创立二级索引，这对于二级索引创立效率是最高的。如果不这么做，每插入一条记录，就要去插入相应的二级索引，那么二级索引就是一个无序的随机插入，并发起来性能会变差很多。
尽管在数据同步筹备好后，批量创立二级索引是一个无效的计划，然而如果数据量很大，这么创立二级索引还是十分耗时，导致客户在数据迁徙完之后须要期待很长时间能力开展业务，这个期待周期可能是小时甚至天级别的。尽管能够思考表级别的并发创立索引，然而这个办法也有显著的毛病：利用场景无限，要求有多表；以及表和表之间的并发其实不是一个最无效的并发模式，相互影响比拟大。
GaussDB(for MySQL)如何疾速创立索引？
综上所述，在创立索引这个点上存在两个性能瓶颈点：一个是用户迁徙数据之后的批量索引创立；第二个是用户长期须要增加一个二级索引。无论哪个点，咱们都须要更快的建设好索引，晋升用户的应用体验。
华为云GaussDB(for MySQL)引入了并行创立索引的技术，它改良了社区版MySQL创立索引只用单线程的问题，以此进步创立索引的效率，并一起解决了前述两个痛点。后面提到的社区版创立索引逻辑是单线程的，首先存在资源利用率不够丰满的问题；其次创立索引过程是CPU和IO开销交替进行的过程，在做一个操作的时候，即便不是资源竞争的操作也只有期待。多线程创立索引能够充分利用CPU和IO资源，同时有的线程在做CPU计算时，别的线程能够并发的做IO操作。
GaussDB(for MySQL)应用的并行创立索引，是一个全链路的并行技术。后面提到，创立索引蕴含了若干个阶段，咱们的并行创立算法，对这里的每个阶段都做并行处理，从读取数据、排序、到创立索引，都是并行操作，每一步都由指定的N个线程并发解决。它的逻辑如下图所示：
GaussDB(for MySQL)尤其对数据的归并排序做了多种优化，使得咱们惯例的归并排序可能充沛的并行，充分利用CPU、内存和IO的资源。在并行创立索引之后的合并步骤，也应用了一套简化的算法，正确处理各种索引构造的场景。
反对的索引和场景
GaussDB(for MySQL)的并行创立索引性能，目前反对的索引为Btree二级索引。对于virtual index二级索引，将会在不久的未来提供全面的反对，而MySQL的spatial index和fulltext index不在该并行创立索引覆盖范围内。
特地要留神的是，主键索引的创立目前也是不反对并行的，因而如果一个并行创立索引的SQL语句蕴含创立主键索引，或者后面提及的spatial index与fulltext index，那么客户端将会收到一个告警，提醒该操作不反对并行创立索引，同时该语句会采纳单线程创立索引的形式执行实现。
从SQL语句的角度，如前所述，创立索引能够采纳不同的算法，因为COPY算法（ALGORITHM=COPY）不是采纳批量插入的形式，因而不会受害于该并行创立索引优化。而对于INPLACE算法，如果创立索引用的是非rebuild的形式，都能够受害于该优化；一旦须要应用rebuild的形式创立索引，因为波及到主键索引的建设，将无奈应用并行创立索引的算法。
示例
上面咱们通过几个实例来理解一下如何应用并行创立索引算法放慢创立速度，以及咱们的条件束缚是如何失效的。
1、咱们应用sysbench的表，表内有1亿条数据
2、在该表的k字段建索引，采纳社区默认单线程，耗时146.82s
3、通过设置innodb_rds_parallel_index_creation_threads = 4启用4个线程建索引，能够看到建索引耗时38.72s，速度晋升3.79倍。
4、假如咱们要批改主键索引，尽管指定了多线程，然而会收到一个warning，实际上只能通过单线程建索引
注意事项
首先对innodb_rds_parallel_index_creation_threads这个参数进行一下阐明，它管制了零碎中所有并行DDL能够应用的总线程数，取值范畴是[1-128]。该参数取值为1示意应用原始的单线程创立索引，取值为N，示意接下来的DDL应用N个线程创立。如果一个DDL应用了100个线程在执行，那么另外一个也要应用并行的DDL且最多只能应用剩下的28个线程；而如果128个线程都被并行DDL语句占用了，新来的DDL只能走原始的单线程创立的逻辑。
尽管该并行创立索引放慢了索引的创立速度，然而在具体应用场景下，还是须要有审慎的评估。咱们晓得在并行算法利用之后，该DDL对硬件资源的应用会尽可能的充沛，这也意味着其它操作就得不到太多的资源了。因而，针对不同的场景须要具体地剖析，它决定了咱们如何创立索引。
对于迁徙场景，因为这时候还没有任何业务接入，用户心愿尽快实现所有索引的创立，因而能够尽量设置多线程数，比方咱们是16核规格的实例，那么咱们就能够把并行线程的数量指定为16，减速实现操作。
如果是用户业务运行阶段要创立索引，咱们还是不心愿DDL操作，对正在运行的业务如DML操作等有太多的影响。因而，这时候创立索引能够指定绝对少一些的线程数量，比方2-4（或者依据CPU规格以及负载决定，同时不激励并发地执行多个DDL操作）。这样既能绝对地减速创立索引的过程，也能保障DML的失常进行。
综上所述，GaussDB(for MySQL)反对了并行创立索引，通过缩短创立索引应用的工夫，很好地解决了客户关切的两类问题，晋升了客户的体验。但技术无止境，在创立索引畛域，还有其它的问题须要咱们优化解决，例如如何缩小创立索引步骤对IO的影响等等。咱们后续会针对这些点进行优化，给客户带来更多的惊喜。
目前，华为云GaussDB(for MySQL) 并行创立索引优化性能已上线，欢送大家返回华为云官网体验：https://www.huaweicloud.com/p...
附：华为云GaussDB(for MySQL)内核专家系列文章
华为海内女科学家为您揭秘：GaussDB(for MySQL)云栈垂直集成的力量有多大？
华为云数据库内核专家为您揭秘：GaussDB(for MySQL)并行查问有多快？
点击关注，第一工夫理解华为云陈腐技术~