本地索引和全局索引的基本概念
在数据库系统中，尤其是分布式数据库或分区表的场景下，索引的设计直接影响查询效率。本地索引（Local Index）和全局索引（Global Index）是两种常见的索引组织方式，它们的核心区别在于索引数据与表数据的分布关系。
假设你管理一个电商平台的订单系统，数据按地区分片存储在北京、上海、广州三个节点。每个节点存放本地区的订单记录。这时候，如果你要在所有地区快速查某个用户的全部订单，索引怎么建就很关键。
本地索引：跟着分区走
本地索引的特点是每个分区都有自己的索引片段，且索引只指向本分区的数据。也就是说，索引的结构和表的分区一一对应。
比如一张按时间分区的订单表，每个月一个分区。你在“订单ID”上建了本地索引，那么1月的索引只管1月的数据，2月的索引只管2月的，彼此不交叉。
这种设计的好处是维护简单。新增或删除分区时，对应的索引也自动增删，不会影响其他分区。适合数据写入频繁、按分区查询为主的场景，比如日志系统。
全局索引：统一调度，跨区查找
全局索引则不同，它是一张独立的、跨越所有分区的索引表。无论数据落在哪个分区，索引都集中管理，能直接定位到具体某条记录的位置。
继续用电商例子。如果你想通过用户手机号查他在全国所有地区的订单，全局索引就能一次性告诉你这条记录在哪个分区，不需要挨个查北京、上海、广州的索引。
但代价是复杂度上升。当某个分区被删除或数据迁移时，全局索引必须同步更新，否则就会出现“指错路”的情况。而且写入性能也会受影响，因为每次插入都要去更新那个集中的索引表。
实际使用中的选择考量
选哪种索引，得看业务需求。如果你的应用大多是按分区范围操作，比如查“本月订单”、“某地区用户”，本地索引更高效也更稳定。
而如果你经常需要跨分区精确查找，比如“查订单号为12345的记录”，那就得靠全局索引撑场面。
以Oracle为例，在分区表上创建索引时可以明确指定：
-- 创建本地索引
<CREATE INDEX idx_order_local ON orders(order_date) LOCAL;>
-- 创建全局索引
<CREATE INDEX idx_order_global ON orders(user_id) GLOBAL;>MySQL的InnoDB虽然原生不支持分区索引的这种划分，但在使用分区表时，其二级索引默认行为更接近全局索引，需要额外设计来模拟本地索引的效果。
再比如Elasticsearch，每个shard内部有独立的倒排索引，这类似于本地索引；但查询时通过协调节点汇总结果，对外提供的是全局视角，算是两者结合的一种实现。