基本概念
数据库分表(分表和分区相比)
- 分表更复杂，但是性能稍微好一点点。但是如果Mysql可以高效的维护各个分区之间的关系的话，其实分表是没有必要的。错误的分表操作，会带来bug
- 分表的性能更好，不需要查询优化器来选择读取哪张表，但是分表编码更复杂，要通过代码指定数据存储到特定的表
数据库分库:(物理层面进行拆分)
- 读写分离：把读和写进行拆分，优势是没有分布式事务的问题，同时编程简单，通过中间件像操作一个数据库一样
- 不同业务的拆分：编程复杂(根据业务选择对应的数据库)，做关联业务联级操作的时候，有分布式事务的问题
- 一个大业务拆分为若干个子业务：编程复杂，分布式事务更严重
如何提升并发写的效率？
已经基于行级锁的话，就没有办法从软件层面提升并发度了，否则会事务冲突。所以思路：行级锁、物理层面提升。
- 弃用Myisam，改用Innodb，基于索引的行级锁技术，支持操作一张表时，并发的写(注意行级锁的使用，尽量避免表锁）
- 读写分离，让主库专注于写，让从库专注于读取（物理提升）
- 数据库分库：把不同的业务拆分到不同的数据库，甚至可以把同一个业务拆分在不同的数据库，引入了编程复杂（根据业务选择对应的子库）和分布式事务的问题（物理提升）
如何提升并发读的效率？
- SQL优化、索引、缓存、参数配置
- 架构调整：分区、分表、分库（读写分离或者业务拆分）
读写分离主从复制的优势
- 主从复制，解决的是容灾类的问题，容灾需要保证数据库切换的实时性和数据的一致性，主机挂了的时候，可以借助中间件，让从机上升为Master
- 读写分离，同时提升了数据库单机的读和写的能力，主库负责写和极少部分的即时性要求高的读，从而提升写的性能。从数据库只要负责读，通过二进制日志的形式批量写，并保持数据和主库一致，合作分工，同时提升读写的性能
- 负载均衡，一主多从下，从库是水平扩展了多个数据库来分摊读的请求（即时性要求不高的读请求），以前一台数据库既负责读又负责写，现在多台数据库分摊读的请求
适用场景：大部分的读操作对数据的实时性要求并没有那么高，一般对时延的容忍在秒级以上
读写分离的本质：用硬件资源和带宽换性能。
Mysql 分区、分表、分库PK
- 分区、分表、分库都可以大幅提升数据库读的性能。
- 数据库分库可以提升并发写的速度：通过简单暴力的物理方式拆分功能
- 分区最简单，由数据库自身维护数据关系；分表复杂，需要开发人员指定数据读写在哪张子表；分库最复杂，除了为对应的数据选择对应的数据库以外，还需要解决跨库的分布式事务问题
- 分区、分表、分库并不冲突，比如在 读写分离的业务场景，对读的数据库的某些表进行分区或者分表。或者对于一些容易编程的表用分表，编程复杂的业务用分区，都是可行的
其它
如果一个业务复杂到分区分表分库仍然解决不了的话，基本上不会出现，一般到了这种量级的数据，早就微服务了，业务拆分，各自业务维护自己的数据库。