垂直拆分和水平拆分经常搞混，按切刀法思路记住了就不会忘

垂直拆分

即纵向拆分，也就是按业务拆分，把业务表分类拆分到不同的库中（或拆分成不同的表）
优点：
1. 拆分后业务清晰，拆分规则明确。
2. 系统之间整合或扩展容易。
3. 数据维护简单。

缺点：
1. 部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。
2. 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
3. 事务处理复杂。
我们可以这样记忆：
一张表 拿刀按纵向切，相当于把一个表里字段拆开成两张表，相当于按业务拆分了（字段粗略理解为不同业务），数据量（数据的条数）没有拆分

水平拆分

即横向拆分，也就是按数据拆分，把一张表的数据拆分到不同的库中（或者分表）
优点：
1. 不存在单库大数据，高并发的性能瓶颈。
2. 对应用透明，应用端改造较少。
3. 按照合理拆分规则拆分，join操作基本避免跨库。
4. 提高了系统的稳定性跟负载能力。

缺点：
1. 分片事务一致性难以解决。
2. 数据维护困难。
3. 跨库join性能较差。
4. 跨节点合并排序分页问题。
我们可以这样记忆：
一张表 拿刀按横向切，相当于把一个表里数据切成两张表，两张表的字段即业务是相同的，数据分开保存了而已

阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。对此，有阿里的黄金铁律支撑，所以，很多人设计大数据存储时，多会以此为标准，进行分表操作

事实上，这个数值和实际记录的条数无关，而与 MySQL 的配置以及机器的硬件有关。因为，MySQL 为了提高性能，会将表的索引装载到内存中。InnoDB buffer size 足够的情况下，其能完成全加载进内存，查询不会有问题。但是，当单表数据库到达某个量级的上限时，导致内存无法存储其索引，使得之后的 SQL 查询会产生磁盘 IO，从而导致性能下降。当然，这个还有具体的表结构的设计有关，最终导致的问题都是内存限制。这里，增加硬件配置，可能会带来立竿见影的性能提升哈。

我之前老是记不住，按这个方法虽然不是很准确，但是很好记