关于MRG_MyISAM的问题

Question

使用MRG_MyISAM引擎分表 比如订单表 （order_1501、order_1502 。。。）

做了一个例子发现：
1. 合并表的数据长度为各分表的长度和，难道合并表是存储数据的？
2. 索引长度为0，难道查询合并表不适用索引？
3. 当数据很大的情况下查询速度变慢 使用分表可以查询慢的问题，但是像time>20120120 或者 pay_money>100 status=2 等需要查询多个分表集合的查询速度会比不分表慢吗？
4. 15年2月份所有订单金额大于200的数据 除了像这种单表查询速度回很快 分表还有其他优势么？

对于使用mrg引擎分表生产环境使用的多吗？ 维护成本怎么样？ 有没有其他分表方案或者处理大数据的方案？

Answer 1

1. 合并表的数据长度为各分表的长度和，难道合并表是存储数据的？

可以这么理解，好吧。我再补充说明一下，便于理解，假设1张大表分成了10份，而这10份查询起来挺麻烦的，就需要一个汇总这10份的表（可以当成一个目录吧），在查询的时候只需要去看目录即可，mysql有自己的实现机制去查到底是去哪张表search

1. 索引长度为0，难道查询合并表不适用索引？

使用修复索引的命令试一下看看

1. 当数据很大的情况下查询速度变慢 使用分表可以查询慢的问题，但是像time>20120120 或者 pay_money>100 status=2 等需要查询多个分表集合的查询速度会比不分表慢吗？

其实你这样分表解决这个问题不太有效，见下。

1. 15年2月份所有订单金额大于200的数据 除了像这种单表查询速度回很快 分表还有其他优势么？

看上去你好像是用order分表的，其实你可以考虑使用年？月？甚至日？，再细化一些可以在年月日基础上加上order，像pay_money这样的条件加索引解决看看怎么样

对于使用mrg引擎分表生产环境使用的多吗？ 维护成本怎么样？ 有没有其他分表方案或者处理大数据的方案？

个人觉得不要盲目的分表，首先考虑的是需求能不能分表，比如说上面的例子，采用order分表，但又需要用日期来索引，这样并不能完好的发挥分表的作用。在做之前先问问自己想要什么？

不清楚你所谓的大数据，这个量是多大？分表也不是万能的，让谁说多少的数据用分表没问题，谁也说不出这种话，这里面的客观条件太多了，比如表里的字段、查询的条件索引、甚至机器的配置……所以你最好是带入数据先测一下。

Answer 2

数据文件对比 article是合并表 其他为分表