数据库分表实践：如何优雅地切换到分表架构
内容提要
文章讨论了多租户数据库设计中的挑战，特别是“共享单表”模式的瓶颈。为解决这些问题，团队实施了按服务维度的数据库分表改造，确保线上服务不受影响，并设计了渐进式切换和回滚机制。通过结构化的迁移流程，团队成功提升了数据库的灵活性和可扩展性。
关键要点
-
采用以游戏为租户单位的多租户数据库设计，初期提高了开发与维护效率。
-
随着游戏数量和业务数据增长，'共享单表'设计暴露出架构瓶颈。
-
启动按服务维度的数据库分表改造，转型为'弹性隔离'架构。
-
实施原则包括不影响线上服务、支持灰度切换和设计可回滚机制。
-
分表工作分阶段进行，逐个服务迁移，确保风险最小化。
-
引入db_mode配置项，按游戏粒度控制读写行为。
-
自动建表逻辑支持新游戏分表，无需人工干预。
-
数据访问层改造遵循只改访问逻辑，不动业务代码的原则。
-
迁移程序设计确保数据不丢失、不重复、不污染新表。
-
上线切换流程分为六个阶段，确保每一步都有验证机制和回滚能力。
-
强调在任意切换阶段发现异常可回退到旧表访问模式。
-
选择依靠MR review和群通知日志确认迁移状态，而非自动标记机制。
-
分表实践为系统架构能力的整体提升，需尽早规划实施。
延伸问答
为什么选择按服务维度进行数据库分表改造？
选择按服务维度进行数据库分表改造是为了避免共享单表设计带来的架构瓶颈，提升数据库的灵活性和可扩展性。
分表改造的实施原则有哪些？
分表改造的实施原则包括不影响线上服务运行、支持灰度切换和设计可回滚机制。
如何确保数据在迁移过程中不丢失？
通过内置的数据迁移子程序，采用幂等执行和主键游标分页查询等策略，确保数据在迁移过程中不丢失、不重复、不污染新表。
分表切换的流程是怎样的？
分表切换流程分为六个阶段，从部署改造程序、双表写入，到逐步切换读写模式，确保每一步都有验证机制和回滚能力。
在分表改造中如何处理异常情况？
在分表改造中，如果发现异常，可以随时回退到旧表访问模式，确保系统的稳定性。
分表实践对系统架构有什么影响？
分表实践提升了系统架构的整体能力，使其更具弹性，能够更好地应对未来的扩展需求。
