MySQL分库分表⽅案
⼀、分库分表背景
1.为什么分库
A.      数据库是最容易产⽣性能瓶颈的服务组件。
数据库连接数资源捉襟见肘和数据库因为表多、数据多造成的性能问题。
这⾥以淘宝为例，在淘宝平台向共享服务体系改造的过程中，通过各个服务中⼼拥有各⾃独⽴数据库的⽅式，即采⽤数据库垂直分区的⽅式对业务数据进⾏分区。
B.      单⼀服务中⼼的数据访问压⼒也必然会达到单机数据库的承载上限，所以在进⾏服务化改造的同⼀时间段内，需要对数据库能⼒做扩展的⼯作。
C.      单台数据库 这⾥以mysql为例，mysql数据库，当访问连接数过多时，就会出现‘too many connections’的错误，⼀般来说是访问量太⼤或者数据库设置的最⼤连接数太⼩的原因。
Mysql默认的最⼤连接数为100。
这个连接连接数可以修改，⽽mysql服务允许的最⼤连接数为16384。
虽然可以通过连接池可以⼀定程序上优化连接，但是当数据量过⼤时，单台数据库显⽰已经不能⽀撑应⽤服务器的访问。
所以就需要做分库，具体分库⽅法下⾯会有详细介绍。
D.      在实际的应⽤中，绝⼤部分情况都是读远⼤于写。
Mysql提供了读写分离的机制，所有的写操作都必须对应到Master，读操作可以在 Master和Slave机器上进⾏，Slave与Master的结构完全⼀样。
⼀个Master可以有多个Slave，甚⾄Slave下还可以挂 Slave，通过此⽅式可以有效的提⾼DB集的 QPS。
所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有⼀定的延迟，当系统很繁忙的时候，延迟问题会更加严重。
Slave机器数量的增加也会使这个问题更加严重。
此外，可以看出Master是集的瓶颈，当写操作过多，会严重影响到Master的稳定性，如果Master挂掉，整个集都将不能正常⼯作。
综上所述：
1. 当读压⼒很⼤的时候，可以考虑添加Slave机器的分式解决，但是当Slave机器达到⼀定的数量就得考虑分库了。
2. 当写压⼒很⼤的时候，就必须得进⾏分库操作。
2.为什么分表
有⼀组数据可以参考：
基本指标:
库物理⽂件⼤⼩<100G
表<100
字段<200
单表记录数<500W
经测试在单表1000万条记录⼀下，写⼊读取性能是⽐较好的。
这样再留点buffer，那么单表全是数字类型的保持在800万条记录以下, 有字符型的单表保持在500万以下。
如果按 100库100表来规划，如⽤户业务:
500万*100*100 = 50000000万 = 5000亿记录。
****供参考，具体按按业务做规划。
3.什么是分区哈夫曼编码树的带权路径长度
分表是将⼀张表分成N多个⼩表，分区是把⼀张表的数据分成N多个区块，这些区块可以在同⼀个磁盘上，也可以在不同的磁盘上。mysql 的分表是真正的分表，⼀张表分成很多表后，每⼀个⼩表都是完整的⼀张表，都对应三个⽂件，⼀个.MYD数据⽂件，.MYI索引⽂件，.frm 表结构⽂件。
⼆、现状
1.淘宝的解决⽅案
1.1⾸先是实施的是数据库的读写分离。
读写分离的基本原理是让主数据库处理事务性增、改、删（Insert、update、delete）操作，
⽽从数据库专门负责处理查询（select）操作，
在数据库的后台会把事务性操作导致的主数据库中的数据变更同步到集中的从数据库。
采⽤读写分离的⽅式，拓展了数据库对数据读的处理能⼒，整体上也⼤⼤提升了数据库的读写能⼒。
但是这样的架构在主数据库的数据写⼊能⼒依然没法扩展，⼀旦数据库写压⼒⽐较⼤时，则对整个平台带来⾮常⼤的影响。
⽽且数据库单表的数据量是有限制的，当单表数据量达到⼀定数量后数据库性能会出现显著下降的情况，所以简单的读写分离不能满⾜淘宝的发展的要求。
1.2 ⾃研cobar分布式数据库
matlab画曲线
为了更好的在数据库层⾯⽀持好淘宝的业务，在2008年，阿⾥巴巴内部开始了分布式数据库的研发⼯作，相关的平台和⼯具陆续登上了淘宝技术发展史的历史舞台。
2006年阿⾥巴巴以开源的形式研发了Cobar这⼀关系型数据库的分布式处理系统。当时Cobar平均每天处理近50亿次的SQL操作，但是随着阿⾥巴巴业务场景越来越复杂，有以下缺点：
1. 不⽀持跨库情况下的连接、分页、排序、⼦查询
2. SET语句执⾏会被忽略，处理事务和字符集设置除外。
3. 分库情况下，insert语句必须包含拆分字段列名
4. 分库情况下，update语句不能更新拆分字段的值
5. 不⽀持SAVEPOINT操作
6. 使⽤JBDC时，不⽀持rewriteBatchStatements = true参数设置
......
1.3 分布式数据层框架TDDL
2008年内部 在Cobar的基础上重新研发了分布式数据层框架TDDL（外号头都⼤了）
TDDL提供了以下优点：
1. 数据库主备和动态切换
2. 带权重的读写分离
3. 单线程读重试
4. 集中式数据源信息管理和动态变更
5. ⽀持MySQL和Oracle数据库
6. 基于JDBC规范，很容易扩展⽀持实现JDBC规范的数据源
7. ⽆Server、client-jar形式存在，应⽤直连数据库
8. 读写次数，并发度流程控制，动态变更
9. 可分析的⽇志打印，⽇志流控，动态变更。
数据类型为什么的字段不能排序
阿⾥巴巴分库分表的⼏个原则：
手机屏幕合成英文>isalpha函数c语言头文件1. 数据尽可能的平均拆分
2. 尽可能的减少事务边界。 所谓的事务边界，指单个SQL语句在后端数据库上同时执⾏的数量。因为事务边界越⼤，系统的锁冲突概率
就越⾼，系统越难以扩展，整体性能越低。
3. 异构索引表尽量降低全表扫描频率。这个是针对假如数据是按订单id进⾏分拆，当⽤户想查看⾃⼰的订单时，针对这种场景，常采⽤
异构索引表来解决，即采⽤异步机制将原表内的每⼀次创建或更新，都换另⼀个维度保存⼀份完整的数据表或索引表。本质上这是互联⽹公司很多时候采⽤的⼀个解决思路：拿空间换时间 。
mysql语句多表查询
实现异构索引的⽅式，也就是阿⾥巴巴内部⽬前采⽤的⽅式 ，通过⼀填名为精卫填海的产品实现了数据的异构复制。
1. 将多条件频繁查询引⼊搜索引擎平台 ⽐如Iucene、Solr、ElasticSearch等搜索引擎。
总结
从系统的风险的⾓度考虑，以8-2法则，在实际中，我们仅针对那些在80%情况下访问的那20%的场景进⾏如数据异构索引这样的处理，达到这类场景的性能最优化，⽽以其他80%偶尔出现跨库join、全表扫描的场景，采⽤最为简单直接的⽅式往往是最有效的⽅式。
2.美团的解决⽅案
通常有两种⽅案。第⼀种⽅案是直接对现有的商品库进⾏垂直拆分，可以缓解⽬前写峰值QPS过⼤、DB主从延迟的问题。
第⼆种⽅案是对现有的商品库⼤表进⾏分库分表，从根本上解决现有问题。
⽅案⼀实施起来周期较短，但只能解决⼀时之痛，由此可见，分库分表是必然的。
2.1 ⾃主研发客户端分库分表中间件MTDDL
在确定分库分表的⽅案之后，调研了外卖订单、结算以及主站等业务的分库分表实现⽅案，也调研了业界很多分库分表中间件。在综合考虑性能、稳定性及实现成本的前提下，最终决定⾃主研发客户端分库分表中间件MTDDL来⽀撑外卖商品分库分表项⽬，这也就是MTDDL的由来。
在MTDDL的设计研发过程中，我们充分考虑了MTDDL的通⽤性、可扩展性、功能的全⾯性和接⼊的便利性。
到⽬前为⽌⼀共开发了四期，实现了MySQL动态数据源、读写分离、分布式唯⼀主键⽣成器、分库分表、连接池及SQL监控、动态化配置等⼀系列功能，⽀持分库分表算法、分布式唯⼀主键⽣成算法的⾼可扩展性，⽽且⽀持全注解的⽅式接⼊，业务⽅不需要引⼊任何配置⽂件。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。