分表分库

笔直分表

简略来说就是拆表，将一张表的字段拆分到多个表中。

这样能够削减对同一条记载可是不同字段的争抢，提高功能。注意text,blob字段这样的大字段，尽量和热门数据区别，防止读取热门数据时和text这样占用大量空间的字段在一张表中，由于text这样的字段占用空间大，形成跨页IO读取，影响热门数据读取功能。

水平分表

水平分表处理单张表数据量过大的问题，将一张表中的数据按路由规则划分到不同表中。水平分表提高了单张表的IO功能，可是仍受数据库实例的IO功能限制。

常用的路由方法有字段hash或许字段映射等。字段hash数据分配的较为均匀，防止分表后数据歪斜；也能够对表中时刻或许区域等字段作为路由依据，一段时刻一张表或许一个区域一张表，可是这样难以应对突发的流量暴增导致数据歪斜。

水平分表后，形成分页排序失效，必须全表扫描都现已这么大数据还分什么页。 关于查询条件中，没有路由信息的，那么也会全表扫描。例如现在现已依照区域(region)分表，可是where条件中不含有region字段，而是要查询指定name，那么就会走全表扫描。 分表之后还或许形成分布式业务的呈现。(暂时没有比如)

笔直分库

和笔直分表差不多，原有数据库实例中或许含有不同模块的表，一旦某个模块呈现流量上升，就会牵连其他模块功能。为了提高可用性，将不同模块表迁移到各自专属的数据库实例。

水平分库

水平分库提高数据库IO功能，进程和水平分表差不多。

分表分库的分布式问题

分表分库带来功能提高，可是也会引进分布式问题。原来单表主键依靠一个自增序列就能够处理，可是分布式场景下，就需要额定引进全局唯一性主键来防止不同表中主键抵触。

• 运用同一自增序列 不同表都运用一个自增序列，这样就能够防止主键抵触。可是一切表依赖一个序列有单点问题，影响可用性，不推荐
• 预留主键id 给每张表预分配一段id。如table1主键在区间1000-1999，table2主键在区间2000-2999，防止主键抵触。可是这样存在诸多危险，不能应对突发流量，一旦预留资源耗尽就需要手动修改。
• 雪花算法
• UUID

此外，路由的逻辑也需要引进到使用中。在客户端引进路由称为客户端分库如sharding-JDBC,还有额定引进署理的proxy分库如Mycat和TDDL。还有自己算表名然后拼上去

读写别离

除了做分表分库之外，还能够规划数据库实例进行读写别离，master实例担任写入，slave担任读取，提高数据库功能。

MySQL主从仿制和Redis主从差不多,master节点记载每一条写入操作到binlog文件中，并入slave节点后将binlog发过去，slave再进行数据同步。

MySQL默认选用异步仿制，不要求主从强共同而是最终共同。master节点写入即以为成功，不考虑slave是否接纳并同步。

如果想要集群强共同，那么能够选用半同步方法，除master写入成功外，还要求对折slave节点接纳并成功同步，这时才会向client返回成功。

参考文献：
[1]: 一次分表踩坑实践的讨论