树叶云带你入门OceanBase，GI功能那些事儿，边学边用不迷路

整理自OceanBase技术社区分享“树叶云带你入门OceanBase：GI功能那些事儿”，旨在用通俗语言介绍核心概念，便于新手理解。）

大家好，我是树叶云，今天我们来聊一聊OceanBase数据库里一个挺有意思的功能——GI，你可能第一次听说这个词，觉得有点专业，别担心，我们今天就把它掰开揉碎了讲，目标就是边学边用,让大家不走弯路。

GI到底是什么？

GI的全称是Global Index，翻译过来就是“全局索引”，这个名字听起来挺大的，但它的想法其实很直接，为了理解它，我们得先知道什么是普通的索引，你可以把数据库的表想象成一本书，书后面的索引就是帮助我们快速找到某个关键词出现在哪些页面的工具，在OceanBase这种能跨多台机器（我们称之为“分布式”数据库）的环境里，一张大表的数据通常会被打散,存放在不同的机器上。

如果我在每台机器上，只为存在本地的数据部分各自建立一个索引，这种索引就叫做“局部索引”，这好比一本多卷册的百科全书，每一册后面都有自己的索引，你要查一个东西，得先猜猜它可能在哪个分册里,然后去翻那个分册的索引。

而GI（全局索引）呢，它想做的就是一件事：给这本分散在多处的“大百科全书”做一个统一的、全局的索引目录，无论数据实际藏在哪台机器上，这个全局索引都能直接告诉你位置，引用来源中的比喻就是：“全局索引的目标是提供一个逻辑上统一的视图”。

GI解决了什么头疼问题？

为什么要费这么大劲搞一个全局索引呢？它主要是为了解决一些局部索引不太擅长的场景，举个例子，假设我们有一张非常庞大的订单表，按照用户ID分成不同的区块，散落在各个机器上，我想根据订单创建时间来做快速的查询，找出最近一小时内创建的所有订单”，如果只有局部索引，数据库的查询引擎就累了，它得向所有存放了订单数据的机器发起询问：“嘿，你那边有一小时内创建的订单吗？”这个过程叫做“全表扫描”或“扫所有分区”，效率比较低，尤其当数据量巨大时,响应就会慢。

但如果我们为“订单创建时间”这个字段建立了一个GI，情况就大不一样了，这个全局索引本身也是一张独立的、特殊的“小表”，它只包含两列关键信息：索引字段（比如创建时间）和原始数据行的“地址”，这张“小表”自己也会被妥善地分布存储，当你执行按时间查询时，优化器会聪明地先去找这个全局索引，快速定位到符合条件的数据行地址，然后再根据地址去精准地获取数据，这样就避免了漫无目的地翻遍所有机器，大大提升了查询速度，引用来源中强调，GI“特别适合非分区键列的查询”。

使用GI需要注意些什么？

好东西也不是没有代价的，GI虽然查询快，但在数据写入、更新或删除时，会带来额外的工作量，因为你需要同时维护原始数据和那个全局的“索引小表”，保证两边的一致性，这就好比你不光要在书里更新内容，还得同步更新后面那个总索引，写操作自然会稍微慢一点点，GI并不是在任何情况下都无脑使用的，它更适合那种“读多写少”的场景，如果你的业务是频繁地写入和修改,那么引入GI就需要仔细权衡一下了。

GI本身也需要占用额外的存储空间,因为它毕竟是独立存在的一套数据结构。

怎么边学边用？

理论说了这么多，动手试试最重要，在OceanBase数据库中，创建一个GI的SQL语法其实很简单，和创建普通索引很像，只是多了一个关键字GLOBAL。

CREATE GLOBAL INDEX idx_order_time ON orders(create_time);

这条命令就是在订单表（orders）上，为创建时间字段（create_time）建立了一个名为idx_order_time的全局索引。

之后，当你执行类似SELECT * FROM orders WHERE create_time > '2023-10-01';的查询时，OceanBase的查询优化器在大多数情况下会自动判断是否可以使用这个全局索引来加速查询,你可以通过查看SQL的执行计划来确认它是否真的用上了你创建的GI。

GI（全局索引）是OceanBase在分布式环境下提供高效查询的一件利器，尤其擅长优化按非分区键进行查询的场景，它的核心价值在于用一点点写性能和存储空间的代价，换来查询性能的大幅提升，希望这次的分享能让你对GI有个直观的认识，下次在你的OceanBase项目中遇到合适的场景，不妨考虑让它登场一试。 基于树叶云在OceanBase技术社区的公开分享整理，旨在普及知识，具体技术细节和实施请以官方最新文档为准。）