继我们去年年底发布内核原生的全局二级索引（用户文档）以来，陆续有客户过来咨询和使用。目前已经有客户在生产实例上大规模使用全局二级索引（Global Secondary Index，下文用GSI代替），大大优化了分区表场景下不含分区键的Query/DML性能以及支持不含分区键的Unique Key能力。阅读我们文章的读者，大部分都是数据库资深使用者和开发人员，应该能体会到这样一个从无到有的功能，在保持MySQL 100%兼容的情况下持续演进，存在大量的工程问题需要解决。因此，在全局二级索引上线之后的这段时间，我们不断补强它的各方面能力，本文将介绍PolarDB内核团队在全局二级索引方面的持续演进工作，并简单总结了目前用户的使用经验。
传统分布式数据库/中间件的平替方案
在需要使用GSI的客户里，我们发现除了本身MySQL分区表的客户以外，有多个客户是从传统的分布式数据库/分布式中间件迁移过来的。这部分客户选择迁移PolarDB MySQL的原因非常清晰：
分布式数据库的易用性/稳定性问题，MySQL的流行很大原因来自于它的简单易用。虽然很多分布式数据库都是宣称MySQL/PG兼容，但是很多情况下SQL的表现和性能，与MYSQL大相径庭。此外，使用者往往需要修改业务来完成数据库的适配兼容，甚至业务上频繁踩坑后才能有所感知。进一步的，业务往往需要感知数据库分库分表的方式，从而尽可能减少跨机多次交互的开销，这非常考验使用者的学习成本和学习能力；
分布式数据库昂贵的成本问题，为了提升scale-out能力，分布式数据库往往采用Share-Nothing的架构，有专门的计算节点/存储节点/元数据节点等等，存在大量的跨机交互。然而，这种设计并不是free lunch，在达到相同性能的前提下，分布式数据库往往需要消耗更多的硬件资源，导致更高的数据库成本。
PolarDB MySQL强大的计算/存储能力，已经能支撑远超传统MySQL数据处理规模的业务。
PolarDB MySQL演进到今天，支持一写多读（最多15个读节点）和多主（最多16个写节点）形态，每个节点最大高达88cores（最新的高性能处理器），存储支持高达100TB的规模（多副本自带修复能力）。在如此规模的计算/存储能力场景下，PolarDB MySQL 100%兼容MySQL，又通过Share-Storage的方式减少了大量的跨机交互成本，在成本、性能、易用性这“不可能三角”之间做到了极致。
很多传统分布式数据库的客户，往往对传统MySQL只能处理千万行规模的表、本地盘停留在TB级别（难以备份和还原）的印象非常深刻，但这也是PolarDB MySQL数年来一直在优化的问题。我们发现，很多从传统分布式数据库迁移过来的客户，在测试了PolarDB强大的处理（16*88cores的读写能力）和百TB规模的存储能力，在评估了效率、易用性、成本、满足业务负载等多个因素后，都选择迁移到了PolarDB MySQL。
用户迁移到了PolarDB MySQL后，根据业务的负载情况和表结构特征，可以选择单表或者分区表的方式。不管是单表还是分区表，我们都提供和MySQL单表/分区表完全一致的使用方式。PolarDB之前有一系列针对大表场景做优化的文章（单表/大表优化），读者可以自行查阅。本文主要侧重PolarDB MySQL在全局二级索引方面的情况，也就是分区表加强方面，读者在阅读之前可以阅读以下文章：分区表增强 和 全局二级索引，对PolarDB分区表&全局二级索引有更深入的理解。
