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主键做索引当然快。
“mysql”达到1亿级别如何设计优化?
1.首先可以考虑业务层面优化,即垂直分表。
垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。
如有多种业务类型,每种业务类型入不同的表,table1,table2,table3.
如果日常业务不需要使用所有数据,可以按时间分表,比如说月表。每个表只存一个月记录。
2.架构上的优化,即水平分表。
水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里,这里不具备业务意义。
如按照id分表,末尾是0-9的数据分别插入到10个表里面。
可能你要问,这样看起来和刚才说的垂直分表没什么区别。只不过是否具备业务意义的差异,都是按字段的值来分表。
实际上,水平分表现在最流行的实现方式,是通过水平分库来实现的。即刚才所说的10个表,分布在10个mysql数据库上。这样可以通过多个低配置主机整合起来,实现高性能。
最常见的解决方案是cobar,这个帖子介绍的比较完善,可以看看。
mysql数据库对1亿条数据的分表方法设计:
目前针对海量数据的优化有两种方法:
(1)垂直分割
优势:降低高并发情况下,对于表的锁定。
不足:对于单表来说,随着数据库的记录增多,读写压力将进一步增大。
(2)水平分割
如果单表的IO压力大,可以考虑用水平分割,其原理就是通过hash算法,将一张表分为N多页,并通过一个新的表(总表),记录着每个页的的位置。
假如一个门户网站,它的数据库表已经达到了1亿条记录,那么此时如果通过select去查询,必定会效率低下(不做索引的前提下)。为了降低单表的读写IO压力,通过水平分割,将这个表分成10个页,同时生成一个总表,记录各个页的信息,那么假如我查询一条id=100的记录,它不再需要全表扫描,而是通过总表找到该记录在哪个对应的页上,然后再去相应的页做检索,这样就降低了IO压力。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)