场景1：数据 I 多，U和D很少，占比15%
场景2：数据 I 多，U和 D 很频繁，占比60%-80%
4 个赞
在生产环境中，对于大表的索引选择，尤其是“全局分区索引”和“全局非分区索引”，需要结合业务场景、数据操作模式及性能需求进行合理选择。以下结合你提供的两个场景进行分析：
场景1：数据 Insert 多，Update 和 Delete 很少，占比15%
在这种场景下，数据写入频繁但修改和删除操作较少，因此对索引的维护成本要求较低，更注重查询效率和写入性能。
全局分区索引（Global Partitioned Index）：
适用于 OLTP 系统，特别是需要频繁进行单条记录查询或精准匹配的场景。
由于索引是全局的，即使表被分区，索引也可以跨分区访问数据，因此适合在查询中使用非分区键列进行过滤。
但其维护成本较高，尤其是在进行表分区操作（如删除、合并等）时，需要手动更新索引，否则索引会失效。
全局非分区索引（Global Non-Partitioned Index）：
适用于 查询频繁、且查询条件不依赖分区键 的场景。
与全局分区索引相比，其维护更简单，因为索引不随表分区变化，但可能无法有效利用分区剪枝（Partition Pruning）。
对于写入频繁、更新少的场景，全局非分区索引在性能上可能略逊于全局分区索引，但维护更简单。
推荐使用：如果查询条件中经常使用非分区键字段，且查询性能要求高，全局分区索引更合适。若查询条件不涉及分区键，全局非分区索引更简单易维护。
场景2：数据 Insert 多，Update 和 Delete 非常频繁，占比60%-80%
这种场景下，索引的维护成本成为关键因素。频繁的更新和删除操作会显著增加全局索引的维护开销，容易导致性能下降或索引失效。
全局分区索引（Global Partitioned Index）：
在频繁更新的场景中，全局索引的维护成本较高，尤其是在进行分区操作时，必须手动更新索引，否则索引会失效。
若频繁更新数据导致索引结构频繁变动，可能影响查询性能。
全局非分区索引（Global Non-Partitioned Index）：
维护成本较低，不依赖于表的分区结构，因此在频繁更新的场景下，更适用于对索引维护要求低的系统。
但其查询效率可能不如分区索引，尤其是在数据量大、分区多的场景下。
推荐使用：在这种频繁更新的场景中，全局非分区索引更合适，因为其维护成本低，不易受频繁 DML 操作影响。若业务上对查询性能要求高，可考虑使用局部索引（Local Index），其维护更简单，且性能更优。
2 个赞
这个问题让我想起了全局非分区索引相关的优化，特别是在Index方面，采用全局分区索引策略很有效。
1 个赞
两个场景都不适合全局分区索引
了解下
场景 1：数据插入（I）多，更新（U）和删除（D）很少，占比 15%
推荐使用全局分区索引
- 原因：全局分区索引会将索引数据分散到多个分区，在高频插入场景下，能分散热点，避免单分区锁冲突和性能瓶颈。由于更新 / 删除操作很少，分区维护的额外开销可以忽略，且分区索引的查询性能更稳定。
- 典型场景：日志表、流水表等只追加写入的大表。
场景 2：数据插入（I）多，更新（U）和删除（D）很频繁，占比 60%-80%
推荐使用全局非分区索引
- 原因：全局非分区索引的单索引结构在高频更新 / 删除时，避免了分区索引的跨分区维护开销（如分区分裂、全局索引重建）。虽然插入时热点相对集中，但在高并发写场景下，整体维护成本更低，性能更稳定。
- 典型场景：交易表、用户行为表等需要频繁更新的业务大表。
ppt 上有一幅图，介绍如何选择
不错