分库分表：
mysql表中最大的数据量为2000万，优化后可以最大达到5000万
原则：
1.能不分就不分
2.数据量太大，正常运维影响正常业务访问
3.表设计不合理，需要对某些字段垂直拆分
4.某些数据出现无穷增长
5.安全性和可用性考虑
6.业务耦合性考虑
方案：
1.垂直拆分 大表拆小表 根据列（字段）进行拆分
优点：数据简单维护
缺点：主键出现冗余，需要管理冗余列
2.水平拆分 某种策略将数据分片来储存 分为库内分表和分库分表两部分，每篇数据会分散到不同的MySQL表或库里面，达到分布式效果，能够支持非常大的数据量
2.1库内分表 解决单一表中数据过大的问题，由于没有把标准共的数据分布到不同的机器上，并没有减轻没有上去看服务器的压力
2.2分库分表 通过主键或者时间等字段进行hash和取模后进行拆分
2.2.1 静态分表 预估最大数据量，根据表需要存的数据来算出需要创建表的数量
2.2.2 动态分表 同样也是对大数据量的表进行拆分，他可以避免静态分表带来的后遗症。当然也需要在设计上多一些东西（这往往是我们能接受的）
3.分库分表难点
3.1跨库join的问题
解决思路：
全局表 字段冗余 数据同步 系统组装
3.2 跨库事务（分布式事务）问题
解决思路：Java应用程序可以采用Atomikos框架来实现XA事务（J2EE中JTA）。感兴趣的读者可以自行参考《分布式事务一致性解决方案》，链接地址：
4.常见的分片规则和策略
4.1 分布式全局唯一id
4.1.1Twitter的Snowflake (雪花算法)最常用的分布式系统项目中使用最多的
SnowFlake 算法，是 Twitter 开源的分布式 id 生成算法。其核心思想就是：使用一个 64 bit 的 long 型的数字作为全局唯一 id。在分布式系统中的应用十分广泛，且ID 引入了时间戳，基本上保持自增的
SnowFlake算法的优点：
（1）高性能高可用：生成时不依赖于数据库，完全在内存中生成。
（2）容量大：每秒中能生成数百万的自增ID。
（3）ID自增：存入数据库中，索引效率高。
SnowFlake算法的缺点：
依赖与系统时间的一致性，如果系统时间被回调，或者改变，可能会造成id冲突或者重复。
4.1.2 UUID/GUID（一般应用程序和数据库均支持）
4.1.3. MongoDB ObjectID（类似UUID的方式）
4.1.4. Ticket Server（数据库生存方式，Flickr采用的就是这种方式）
4.2分片字段如何选择：
4.2.1随机分片 我们会采用Hash取模的方式进行分片拆分
4.2.2连续分片
4.3 数据迁移 容量规划，扩容等问题
4.3.1数据迁移 一般做法就是通过程序先读出历史数据，然后按照指定的分片规则再将数据写入到各个分片节点中。
需要根据当前的数据量和QPS等进行容量规划，综合成本因素，推算出大概需要多少分片（一般建议单个分片上的单表数据量不要超过1000W）
