mysql 如何处理亿级数据

1、数据表 collect ( id, title ,info ,vtype) 就这4个字段，其中 title 用定长，info 用text, id 是逐渐，vtype是tinyint，vtype是索引。这是一个基本的新闻系统的简单模型。现在往里面填充数据，填充10万篇新闻。　

2、最后collect 为 10万条记录，数据库表占用硬盘1.6G。OK ,看下面这条sql语句：select id,title from collect limit 1000,10很快；基本上0.01秒就OK，再看下面的select id,title from collect limit 90000,10从9万条开始分页。

3、8-9秒完成。

4、看下面一条语句:select id from collect order by id limit 90000,10很快，0.04秒就OK。因为用了id主键做索引当然快。

小服务器 2G 内存 单核 专门的Mysql服务器 innondb引擎

3万条 插入 每行大约有 300多个字节的数据 大约执行 2分钟

有自动递增主键

这样算的话 可能 需要 6000分钟？ 100小时 还好了

单表一亿？还是全库1亿？

1.首先可以考虑业务层面优化，即垂直分表。

垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。

如有多种业务类型，每种业务类型入不同的表，table1,table2,table3.

如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月记录。

2.架构上的优化，即水平分表。

水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。

如按照id分表，末尾是0-9的数据分别插入到10个表里面。

可能你要问，这样看起来和刚才说的垂直分表没什么区别。只不过是否具备业务意义的差异，都是按字段的值来分表。

实际上，水平分表现在最流行的实现方式，是通过水平分库来实现的。即刚才所说的10个表，分布在10个mysql数据库上。这样可以通过多个低配置主机整合起来，实现高性能。

最常见的解决方案是cobar，这个帖子介绍的比较完善，可以看看。

http://blog.csdn.net/shagoo/article/details/8191346

cobar的逻辑层次图：

不过这种分库方式也是有一定局限性的，需要应用程序做相应的配合，比如说分库的情况下，虽然可以实现跨库查询，但是不能进行相关的group by计算。

另外，之前关于水平分表的实现方式，也可以通过表分区来实现。

mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。

而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。

相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。

分区只需要一次本地数据迁移的 *** 作。

而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。

一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。

---