此文章写的没经过目前第二种方法测试，第一种方案比较成熟了。
分库，分表，分区，都是为了适应大量数据的存储，简称一下就是一个很牛逼的一个词，大数据
分区的文章到处都有，但是实际上讲分表的确实不多，绝大多数只是讲一下分表的思想和理论，还有一些是介绍一些，第三方插件或者组件
那么mysql本身是否可以直接实现分表的，是完全可以，但是又有限制的。
其实需要分表的也就几哥表，比如，博客的用户，文章表，电商的订单，商品，用户，评论表，不是所有的表需要分表。
目前有2中比较可行的方案：
1，myisam表引擎，根据路由规则来划分子表，比如，每一百万分一张表，order_1，order_2，order_3，order_4，order_5，order_6，order_7......order_10
order_1 1-100万 ，order_2 100万-200万，这样来划分，单表百万，有索引，速度完全不是问题，但是想贴吧那种变态的单贴上亿的，目前mysql做核心表，不太可能。
oracle的解决方案估计才能可行，不要死于技术，要活用。
在定制路由规则的时候，update，delete的时候计算order_id就算表名，就可以操作，最重要的是查询可以使用mrgmyisam表引擎来合并总表作为查询的，增加操作在查询最大的order_id，
计算找到表名，进行插入操作，注意这个和视图不一样，也比较类似，但是mrgmyisam就是专门做这个用的第三方引擎。
但是也比较类似，最好不要增删改在这里操作，还是使用经过路由规则的封装方法来操作，这种还是可以联表查询的，唯一的一个大缺点就是不支持事务，因为生产环境
在核心操作的都是有事物回滚，不然数据不一样就麻烦了
2，innodb 引擎，和上面的差不多，但是innodb没有类似mrgmyisam的引擎，需要使用视图在做查询，做联表，但是这个在做分表，在建视图的时候，需要特别注意这个视图的性能，毕竟这个视图特别大，
也有事务，所以比较适合大多数的业务需求。
因为还没测试视图的性能所以比较担心，联表也是大问题。
2017年7月17日18:39:25，目前有一个还行的临时解决方案，就是比如如果最近三个月，或者最近半年的查出来单独做个查询表或者视图，其实这样的话视图更好，比如电商的历史订单，
但是新闻或者其他的这样方案效果也一般，但是也是一个比较好的解决方案。
在全局ID生成上可以使用类似UUID这样的，使用一张其他表专门来生成，但是也有缺陷，我个人建议这种根据路由规则生成，比较靠谱。
flickr 这个MySQL好像也可以使用
https://www.mysql.com/customers/view/?id=720
其实分库比分区简单，业务直接把模块的业务和表，分在不同的数据库里，需要有比较严格逻辑和开发者的要求高，因为你无法联表，需要维持数据在php业务，特别是需要大分页，多库查询之后，php会不会内存超出。
，页面显示需要在代码逻辑里面去拼接数据。
但是等分库的数据了更大了之后，依然需要分表，刚好分表的实际实施技术网上比较好。
其他的一些插件，Atlas，cobar，TDDL等，是通过复杂算法来实现的逻辑的，但是比较方便开发者。
但是国产这些插件，基本属于人走茶凉类型，很容易不更新，不维护。所以，哎。
通过逻辑来实现，就是比较适合我们一般中小应用的扩容。