面试系列-mysql分库分表

数据库性能瓶颈

1. 数据库连接数据库连接是非常稀少的资源，MySQL数据库默认100个连接，单机最大1500连接；
2. 数据量MySQL单库数据量在5000万以内性能比较好，超过阈值后性能会随着数据量的增大而变弱；MySQL单表的数据量是500w-1000w之间性能比较好，超过1000w性能也会下降；
3. 硬件问题因为单个服务的磁盘空间是有限制的，如果并发压力下所有的请求都访问同一个节点，肯定会对磁盘IO造成非常大的影响；

数据库性能优化演变

参数优化 ===> 缓存、索引 ====> 读写分离====> 分库分表 （最终方案）

分库分表的几种方式

垂直拆分

优点：

1.拆分后业务清晰（专库专用按业务拆分）；

2.数据维护简单，按业务不同，业务放到不同机器上；

缺点:

1.如果单表的数据量，写读压力大；

2.受某种业务决定，或者被限制，也就是说一个业务往往会影响到数据库的瓶颈（性能问题，如双十一抢购）；

3.部分业务无法关联join，只能通过java程序接口去调用，提高了开发复杂度；

数据库垂直拆分

表垂直拆分

水平拆分

优点：

1.单库/单表的数据保持在一定量（减少），有助于性能提高；

2.提高了系统的稳定性和负载能力；

3.拆分表的结构相同，程序改造较少；

缺点:

1.数据的扩容很有难度维护量大；

2.拆分规则很难抽象出来；

3.分片事务的一致性问题部分业务无法关联join，只能通过java程序接口去调用；

数据库水平拆分

表水平拆分

常见的取模、range、hash来拆分；

1. hash分发,优点：可以平均分配每个库的数据量和请求压力 缺点：扩容起来比较麻烦，会有一个数据迁移的这么一个过程；
2. range来分,每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了,优点：扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了 缺点：大部分的 请求，都是访问最新的数据。实际生产用range，要看场景，你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据；

分库分表带来的问题

1. 分布式事务

采用补偿事务，例如TCC来解决分布式事务问题；

用记录日志等方式来解决分布式事务问题；

1. 跨库join查询

将有E-R关系的表存储到一个库中；

对于数据量少的表建成全局表，分布到各个库中；

对于必须跨库join的，最多支持跨两张表的跨库join

1. 分布式全局唯一id

利用Redis的incr命令生成主键；

用分布式id服务生成主键；

利用snowake算法生成主键。

分库分表实现技术

分库分表的开源框架 jdbc 直连层：shardingsphere、tddl proxy 代理层：mycat，mysql-proxy（360）

jdbc直连层和proxy代理层优缺点

• jdbc直连层性能高，只支持java语言，支持跨数据库
• proxy代理层开发成本低，支持跨语言，不支持跨数据