大数据处理用mysql速度怎么样

您好，主要是检索某段时间内的模拟量值（select * from table where datatime between t1 and t2 ）,目前打算使用分表，分区的方式解决

不纸上谈兵，说一下我的思路以及我的解决，抛砖引玉了
我最近正在解决这个问题
我现在的公司有三张表，是5亿的数据，每天张表每天的增量是100w
每张表大概在10个columns左右
下面是我做的测试和对比
1.首先看engine,在大数据量情况下，在没有做分区的情况下
mysiam比innodb在只读的情况下，效率要高13％左右
2.在做了partition之后，你可以去读一下mysql的官方文档，其实对于partition，专门是对myisam做的优化，对于innodb，所有的数据是存在ibdata里面的，所以即使你可以看到schema变了，其实没有本质的变化
在分区出于同一个physical disk下面的情况下，提升大概只有1％
在分区在不同的physical disk下，我分到了三个不同的disks下，提升大概在3％，其实所谓的吞吐量，由很多因素决定的，比如你的explain parition时候可以看到，record在那一个分区，如果每个分区都有，其实本质上没有解决读的问题，这样只会提升写的效率。
另外一个问题在于，分区，你怎么分，如果一张表，有三个column都是经常被用于做查询条件的，其实是一件很悲惨的事情，因为你没有办法对所有的sql做针对性的分区，如果你只是如mysql官方文档上说的，只对时间做一个分区，而且你也只用时间查询的话，恭喜你
3.表主要用来读还是写，其实这个问题是不充分的，应该这样问，你在写入的时候，同时并发的查询多么？我的问题还比较简单，因为MongoDB的shredding支持不能，在crush之后，还是回到mysql，所以在通常情况下，9am－9pm，写入的情况很多，这个时候我会做一个view，view是基于最近被插入或者经常被查询的，通过做view来分离读取，就是说写是在table上的，读在进行逻辑判断前是在view上操作的
4做一些archive table，比如先对这些大表做很多已有的统计分析，然后通过已有的分析＋增量来解决
5如果你用mysiam，还有一个问题你要注意，如果你的.configure的时候，加了一个max index length参数的时候，当你的record数大于制定长度的时候，这个index会被disable
6

照你的需求来看，可以有两种方式，一种是分表，另一种是分区
首先是分表，就像你自己所说的，可以按月分表，可以按用户ID分表等等，至于采用哪种方式分表，要看你的业务逻辑了，分表不好的地方就是查询有时候需要跨多个表。

然后是分区，分区可以将表分离在若干不同的表空间上，用分而治之的方法来支撑无限膨胀的大表，给大表在物理一级的可管理性。将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。分区的好处是分区的优点：

1　增强可用性：如果表的一个分区由于系统故障而不能使用，表的其余好的分区仍然可以使用；

2　减少关闭时间：如果系统故障只影响表的一部分分区，那么只有这部分分区需要修复，故能比整个大表修复花的时间更少；

3　维护轻松：如果需要重建表，独立管理每个分区比管理单个大表要轻松得多；

4　均衡I/O:可以把表的不同分区分配到不同的磁盘来平衡I/O改善性能；

5　改善性能：对大表的查询、增加、修改等操作可以分解到表的不同分区来并行执行，可使运行速度更快；

6　分区对用户透明，最终用户感觉不到分区的存在。