MySQL分库分表

        MySQL但数据库的量在5000万以内性能比较好，超过阈值后性能会随着数据量的增大而变弱。MySQL单标的数据量是500W-1000万之内性能会比较好，超过1000w性能也会下降。磁盘因为单个服务的磁盘空间是有限制的，如果并发压力下，所有的请求都访问同一个节点，肯定会对磁盘IO造成很大的影响。数据库连接数据库是非常稀有的资源，还来那个数据同时操作的时候会产生瓶颈。

        单个库太大时，如果是表太多，则应该将部分表进行迁移（可以按照业务进行区分）进行垂直切分；如果是数据量过大，则需要将表拆分成更小的表减小单表的数据量，这就是水平拆分。简单来讲：垂直拆分是对表的拆分，水平拆分是对单个数据表的拆分。

【垂直分表】

        也就是大表拆小表，基于字段进行的，一般是表中字段较多，将不常用、数据较大、长度较长的拆分到扩展表。一般是针对那种几百列的大表，也避免查询时数据量太大造成的跨页问题。

【水平分表】

        水平分表和垂直分表有一点类似，不过垂直分表是基于列的，而水平分表是基于全表的。水平拆分可以大大减小单标数据量，提升查询效率。水平分库分表将单张表的数据切分到多个服务器上，每个服务器具有相应的库与表只是表中数据集合不同。水平分库分表能够有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

【常用的分库分表的策略】

HASH取模，范围分片，地理位置分片，时间分片（可以做到冷热数据）

【分库分表产生的问题】

（1）分布式事务

垂直分库或者水平分库之后，就必然会涉及到跨库执行SQL的问题，这样就引发了“分布式事务”。解决方案：1）使用分布式事务中间件；2）使用MySQL自带的针对跨库的事务一致性方案XA，不过性能要比单库的慢10倍；3）尽量避免跨库操作（将用户和商品放到同一个库中）。

（2）跨库join问题

分库分表之后表之间的关系将受到限制，位于不同库的表是不能join的，也不能join分表粒度不同的表，结果原本一次查询可能需要多次查询。

大概解决方案：全局表（基础数据，所有库都拷贝一份）；系统层组装：分别查出所有，然后组装起来，较复杂。

（3）横向扩容问题

当我们使用hash取模做分表的时候，针对数据量的递增 ，可能需要动态的增加表，此时需要考虑因为reHash导致的数据迁移问题

（4）结果集合并、排序问题

因为我们是将数据分散存储到不同的库、表里的，当我们查询指定数据列表时，数据来源于不同的子库或者子表，就必然会引发结果集合并、排序问题。如果每次查询都需要排序、合并等操作，性能肯定会受非常大的影响。走缓存可能一条路!使用分库分表中间件MycatMycat发展到现在，适用的场景已经很丰富，而且不断有新用户给出新的创新性的方案，以下是几个典型的应用场景:单纯的读写分离，此时配置最为简单，支持读写分离，主从切换分表分库，对于超过1000万的表进行分片，最大支持1000亿的单表分片多租户应用，每个应用一个库，但应用程序只连接Mycat，从而不改造程序本身，实现多租户化报表系统，借助于Mycat的分表能力，处理大规模报表的统计替代Hbase，分析大数据作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时Mycat可能是最简单有效的选择.Sharding-JDBC当当网开发的简单易用、轻量级的中间件