随着互联网应用的广泛普及，海量数据的存储和访问成为系统设计的瓶颈。对于一个大型的互联网应用来说，每天几十亿的PV无疑对数据库造成了非常高的负载。给系统的稳定性和扩展性造成了很大的问题。通过数据切分来提升网站性能，横向扩展数据层成为架构开发者的首选方式。mysql主从复制原理主要涉及三个线程：binlog线程、I/O线程和SQL线程。binlog线程：负责将主服务器上的数据变化写入二进制日志（Binarylog）。I/O线程：负责从主服务器读取二进制日志，并写入从服务器的中继日志（Relaylog）。SQL线程：负责读取中继日志，解析出主服务器执行过的数据变更，并在从服务器上重放（Replay）。这张图清楚的表达了流程1：主库db的更新事件（update，insert，delete）写入binlog2：从库发起连接，连接到主库3：此时主库创建一个binlogdumpthread线程，将binlog的内容发送到从库4：从库启动后，创建一个I/O线程从主库读取binlog内容并写入中继日志5：会同样创建一个SQL线程从relaylog中读取内容，从Exec_Master_Log_Pos位置执行读取更新事件，将更新内容写入slavedb。主从同步复制模式：读写分离：MYSQL读写分离的原理其实就是让Master数据库处理事务的增删改查操作（CREATE、INSERT、UPDATE、DELETE），而让Slave数据库处理SELECT操作。MYSQL读写分离的前提是基于MYSQL主从复制，可以保证数据在Master上修改。Slave同步后，WEB应用程序可以从Slave端读取数据。数据库分区：分区不是生成一个新的数据表，而是将表的数据均匀分布到不同的硬盘、系统或不同服务器的存储介子上。其实还是一张桌子。另外，分区可以将表的数据均衡到不同的地方，提高数据检索的效率，减少数据库频繁的IO压力值。分区的优点如下：与单一的文件系统或硬盘相比，分区可以存储更多的数据；数据管理更方便。例如，如果要清理或丢弃某年的数据，可以直接删除该日期的分区数据；精确定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率；多分区磁盘查询，提高查询吞吐量；当涉及到聚合函数查询时，可以方便地合并数据；1.水平分区是对表的行进行分区的一种分区形式，通过这种方式进行不同的分组内部按物理列分区的数据集可以合并进行单独分区（单个分区）或集体分区（一个或多个分区）。表中定义的所有列都可以在每个数据集中找到，因此表的标识得以保持。2.垂直分区这种分区方式一般是通过对表进行垂直分区来减小目标表的宽度，从而将一些特定的列划分为特定的分区，每个分区都包含与其对应的列。好的。什么时候应该考虑使用分区？表的查询速度已经慢到影响使用。SQL已优化。对数据量大的表中的数据进行分段。对数据的操作往往只涉及部分数据，而不是全部数据。相应的，查询所需的时间也在增加，相当于数据处理遇到了瓶颈。当单个数据库发生事故时，需要修复所有数据，而多个数据库中的一个发生事故。当你只需要修复一个数据库时（当然你也可以使用物理分区来处理这个问题）什么时候考虑使用分库？单个DB的存储空间不够用。随着查询量的增加，单台数据库服务器无法通过支持分库来解决问题：其主要目的是突破单节点数据库服务器的I/O能力限制，解决数据库的可扩展性问题。在垂直拆分中，系统中不存在或需要join的表可以放在不同的数据库和不同的服务器中。按业务垂直划分。例如：按照业务可以分为资金、会员、订单三个数据库。待解决的问题：跨库事务，Jion查询等。横向拆分比如大部分站点。数据都是和用户相关的，所以数据可以按照用户级别来拆分。按照规则，一般横向分库之后是纵向分库。例如，每天处理的订单数量是海量的，可以按照一定的规则进行划分。待解决问题：数据路由、组装。什么时候应该考虑拆分表？表的查询速度已经慢到影响使用。SQL做了优化，数据量大。当频繁插入或联合查询时，速度变慢。分表解决的问题。分表后，提高了单表的并发能力，也提高了磁盘I/O性能，提高了写操作的效率。查询一次数据分布在不同的文件中，提高了磁盘I/O性能。减少了受读写锁影响的数据量。插入数据库的数据需要重新建立索引。需要重新索引的数据减少了。这是最常见的数据库设计。比如数据库db中有一张用户（user）表，所有的用户都可以在db库中的user表中找到。单库多表随着用户数量的增加，用户表的数据量会越来越大。当数据量达到一定程度时，对user表的查询会逐渐变慢，从而影响整个DB的性能。如果用mysql，问题就更严重了。当需要增加一列时，mysql会锁住表，所有的读写操作只能等待。可以通过某种方式对用户进行水平切分，生成两张user_0000、user_0001等表结构完全相同的表，user_0000+user_0001+……的数据就是一个完整的数据。随着数据量的增加，单个DB的存储空间可能不足以容纳多个数据库和多个表。随着查询量的增加，单一的数据库服务器已经无法支撑了。这时候就可以水平拆分数据库了。数据库知识补充：MySQL使用自增ID主键和UUID作为主键优缺点对比详细过程（从百万到千万表记录测试）（1）单实例或单节点组：500W、1000W单机表测试，自增ID与UUID相比，自增ID主键性能高于UUID，磁盘存储成本是UUID的一半。因此，在单个实例或单个节点组上，使用自增ID作为首选主键。（2）分布式架构场景：在20个节点组以下的小规模分布式场景中，为了快速实现部署，可以使用UUID主键来快速部署，消耗更多的存储成本，牺牲部分性能；20~200个节点组对于中等规模的分布式场景，可以采用自增ID+步长的较快方案。对于超过200个节点组的大数据下的分布式场景，可以使用推特雪花算法构建的全局自增ID作为主键。
