MySQL分库分表
高并发系统中，数据只用一张表或者一个库存储会大大地限制性能，所以我们可以进行分库分表来性能提升。
垂直方向
用户表 中的字段太多，我们一些业务场景只需要用户信息的部分，就可以将用户表拆分成 用户基本信息表 和 用户详细信息表 。根据业务需求分开查询。（垂直分表）
数据库中有很多个库，每个库中保存的表都错综复杂，没有章法。所以我们将所有的 用户表 集中放在一个库中，所有的 订单表 集中放在一个库中，所有的 商品表 放在另外一个库中。（垂直分库）
水平方向
用户太多了，即使是 用户基本信息表 单表中的记录太多导致查询起来依旧很慢，所以我们可以将这张单表拆分成多个表存储，分别用user_db0, user_db1, user_db2… 等来保存用户数据。（水平分表）
如果每个库已经按照需求划分了，用户库 中的数据量依旧很大，就需要将其中的部分数据移到另外一个库中存储。所以，水平分库和水平分表常常是不分家的。水平分库也意味着水平分表。（水平分库）
实际案例
个人理解：一个表的字段过多的时候，各个字段的访问频率又不均的情况下，我们就可以考虑 垂直分表 ；单表的数据量过大，导致查询效率下降的情况下，我们就可以考虑 水平分表 ；业务复杂，模块之间互相独立的情况下，我们可以考虑 垂直分库 ；单库连接数有限制，并发量太大，单库存储可能会导致连接数耗尽，我们可以考虑 水平分库 。
场景1： 用户表字段过多，且大部分字段不常用，但查询时都在同一个表操作。单表已有千万条数据，单库连接数充足。
应该将这个用户表 垂直分表 ，将常用的少量字段放在一个用户表中，其余字段放在另外一张表中。
场景2： 一个游戏充值系统，单日订单量高达千万，且订单查询常按用户ID精确查找。数据库连接数达到瓶颈，查询写入均受影响。
数据率很大，且数据库连接达到瓶颈证明并发量很高，考虑使用 水平分表 + 水平分库。
场景3： 某电商系统，用户、订单、商品表都在同一个库，随着业务发展连接数接近最大值，且不同业务模块团队独立运维。
垂直分库
场景4： 某积分系统，单表数据量非常大（亿级），但访问并发不高，大部分查询是根据用户ID精确查询，写入写的较多。
水平分表
场景5： 有一个用户信息表，既存储用户基本信息，也存储大量可选的扩展属性（JSON格式），字段很多且更新频率不同。
垂直分表
场景6： 一台服务器运行一个MySQL实例，同时部署多个业务服务，数据库经常出现“Too many connections”报错。
垂直分库
场景7： 日志系统，日志每天几亿条，查询按时间和日志类型范围扫描。
每天几亿条，水平分库分表，按照时间来分区最合适。