准备把一套 MySQL 业务迁到 OB，原来用的是 AUTO_INCREMENT 自增主键。
了解到现在更推荐用有序的分布式 ID（比如雪花算法那种），但改动量不小。想请教：
- OB 里自增列在分布式场景下有什么坑？
- 如果继续用自增，需要注意什么（热点？）？
- 换成业务侧生成 ID，大家的实践是怎样的？
有迁移经验的朋友指点下。
1 个赞
从 MySQL 迁移到 OceanBase：自增主键和分布式 ID 的规划建议
OB 里自增列在分布式场景下的注意事项
根据文档库中的信息，OceanBase 数据库中使用自增列作为分区键时需要注意以下几点：
-
全局唯一但不保证递增：
- 在 OceanBase 数据库中，自增列的值全局唯一，但在分区内不保证递增。
- 使用自增列作为分区键时，插入操作可能无法有效路由，产生跨机事务，导致性能下降。数据分布 → 分区 → 分区注意事项
-
跳变问题：
- 自增列支持两种模式：
ORDER和NOORDER。默认为ORDER模式。-
ORDER模式：基于集中缓存的自增列，保证全局递增。 -
NOORDER模式：基于分布式缓存的自增列，仅保证全局唯一。
-
- 在分布式环境下，为了保证自增列生成的性能，可能会出现自增值生成过程中的跳变问题。定义自增列 → 关于自增列 → 自增列的跳变
- 自增列支持两种模式：
如果继续使用自增主键，需要注意什么？
-
热点问题：
- 由于自增列的特性，在高并发写入场景下，可能会出现热点问题，特别是在单个分区的情况下。
- 可以通过增加分区数量来分散写入压力，但这会增加跨机事务的可能性。
-
性能优化：
- 确保自增列的模式设置为
ORDER，以保证全局递增，减少跳变问题。 - 考虑使用多表分区或其他方式来分散写入压力，避免单点热点。
- 确保自增列的模式设置为
换成业务侧生成 ID 的实践
如果决定使用业务侧生成的分布式 ID（如雪花算法生成的 ID），可以参考以下实践：
-
ID 生成服务：
- 部署一个专门的 ID 生成服务，使用雪花算法或其他分布式 ID 生成算法。
- 该服务需要保证高可用性和高性能，以应对高并发请求。
-
应用层改造：
- 修改应用程序代码，将自增主键替换为由 ID 生成服务提供的分布式 ID。
- 确保所有涉及主键的操作（如插入、更新、查询）都使用新的分布式 ID。
-
数据迁移：
- 在迁移过程中，确保新旧 ID 的映射关系正确无误。
- 使用 OMS 或其他数据迁移工具进行数据迁移，确保结构迁移、全量迁移和增量同步的顺利进行。使用 OMS 从 MySQL 数据库迁移数据到 OceanBase 数据库 MySQL 租户 → 背景信息
总结来说，如果你决定继续使用自增主键，需要关注热点问题和性能优化；如果选择使用分布式 ID，则需要进行应用层的改造和部署专门的 ID 生成服务。无论哪种方案，都需要仔细规划和测试，确保迁移过程的顺利进行。
具体信息可参考以下文档: