在OceanBase MySQL模式分区表业务中，想咨询LOCAL局部索引与GLOBAL全局索引的选型方案。如果业务存在跨分区字段唯一约束，必须使用全局索引，想了解全局索引会带来哪些DML性能损耗，在生产环境有哪些可行的优化手段？
12 个赞
与局部索引相比，由于全局索引有独立的分区规则，因此索引表中一个分区的索引值可能对应着主表的多个分区内的数据。由于索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起，这不可避免的会引入读写的 RPC 代价和分布式事务的代价。例如：当主表的分区和全局索引的分区不在同一个物理位置上，TABLE SCAN 算子执行全局索引表扫描时就会包含一次 RPC 操作到远端机器上去获取主表数据。因此全局索引相比局部索引有更高的维护代价，您应当充分评估主表的分区规则，合理的选择分区键，尽量使更多的查询条件能够覆盖主表的分区键，从而尽可能的避免使用全局索引。
出自：
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006619144
6 个赞
全局索引写入需要同步维护分区表与索引分区，DML会产生分布式事务，开销明显高于局部索引。高频更新场景延迟上涨、锁冲突概率增加。
优化思路：优先改造业务，尽量规避跨分区唯一约束；无法改造时控制事务大小，降低并发。合理规划分区键，减少索引跨节点访问，严控全局索引上的批量操作。
6 个赞
优化手段
- 合理设计分区键：确保分区键的选择能够最大限度地减少跨分区操作的需求。例如，如果业务查询经常涉及非分区键的字段，考虑重新设计分区策略；
- 使用批量操作：批量处理DML操作可以减少对全局索引的频繁更新，从而减少性能损耗。例如，使用INSERT INTO … SELECT语句或批量UPDATE和DELETE操作；
- 优化事务大小：尽量减少单个事务中的操作数量，这可以减少因锁竞争和日志写入导致的性能问题；
- 硬件升级：增加服务器的CPU和内存资源可以提升处理能力，特别是在执行复杂查询或大量DML操作时；
- 定期维护：定期对数据库进行优化和维护，如重建索引、更新统计信息等，可以保持数据库性能的稳定。
- 使用合适的存储引擎和配置：OceanBase提供了多种存储引擎和配置选项，根据具体业务场景选择合适的配置可以显著提升性能。
通过上述方法，可以在保证数据一致性和完整性的同时，尽量减少使用全局索引带来的性能损耗。在实际应用中，还需要根据具体的业务场景和测试结果来调整策略。
3 个赞
这个问题涉及到OceanBase和例如的平衡，根据我的经验，适当调整MySQL模式分区表会有帮助。
3 个赞
感谢分享q
2 个赞
这两种索引确实不太容易理解
2 个赞
好问题
1 个赞
跨分区事务增加
1 个赞
66666
支持支持
很好
非常有深度的一篇好文，点赞支持。
看完这篇文章，我对这个话题有了新理解。
关于OceanBase的讨论很有价值，特别是在AntTech场景下，合理使用RPC是关键。
这个问题让我想起了OceanBase相关的优化，特别是在AntTech方面，采用RPC策略很有效。