一般表记录数快速增长的做水平表（比如日志表、流水表等）， 表记录数增长缓慢且知道最大增长到多少的做垂直表， 表记录数快速增长的做全局表/广播表（比如参数表、配置表） 金融行业一般用机构号来做分片的较多...

业务本身设计，我不专业就不班门弄斧了。从容器平台方面，可以简单说一下。容器本身就能够实现多集群多实例的部署，并且当实例异常后，也可以重启一个新的实例。因此，业务做微服务改造后，只要保证每个服务有多实例存活，就可以提供高可用。通常双活方案，都是在平台之前加一个全局负载...

分库分表分区是解决大数据量时的一个分而治之的思路，建议依次考虑的顺序如下1.分区：表分区之后只是引擎存储的工作去保证，对用户相对透明，因为对应用侵入度较低；2.分表：在同一个schema中的多个表，应用可能需要根据业务逻辑去判断业务对应的表，这种情况下单库内路由也相对比较好办...