MySQL大数据优化

我们考虑的情况是在你的数据量很大的情况下,千万级别的数据量。不要当我们的请求响应时间已经让我无法忍受的时候,再来想起来优化,可能有点迟了。因为可能会丢失很多潜在的价值客户。所以,在我们当初设计表,或者因为我们的业务的变化而导致的情况下,就要多多考虑去优化我们的MySQL了。

1、在我们的开发中,请务必注意我们的sql书写,可能你的一个sql导致全站挂掉了。所以要优化好我们的sql,这其中不得不说,索引。SQL 的优化和索引 密不可分。优化SQL 一部分是业务逻辑的优化,一部分就是索引的优化。至于怎么优化,网上太多了。也可以看我其他文章有介绍。

2、当我们觉得上面的做的很不错了,还是访问慢,考虑下加缓存把。这里的缓存可以是 A文件缓存 B MySQL的buffer C Nginx或者Apace的缓存设置  D客户端浏览器的缓存  E 更重要的是NOSQL类型的缓存,增加memcache 和 redis。确实好,基于内存的读写自然比操作硬盘快把

3、我们的数据量还在增加,我们就考虑下MySQL的读写分离了,进而涉及到主从复制等情况,不过这里需要对SQL 语句进行稍微改动下。要不怎么知道读哪台服务器,写哪台。

4、接下来,我们考虑我们的业务了,随着并发量不断增加,老板这时候开心坏了。这都是钱啊。那就分表把。100万条记录的表,分5张 10张都行。不过前提需要按照一定的规则的,比方id为1的在member1表,2的在member表,一次类推;或者啊id在1-100的在1表,101-200的2表,以此类推。意思就是这样的。不过需要我们在sql的时候,写好读哪个表,写那个表的规则。其实也简单。

5、区分热表和冷表。也就是垂直切分表了。顾名思义,热表代表经常更新的,操作比较频繁的,冷表,则相反。

这其中我们需要考虑以下问题

表引擎的选择。在几年前默认就是Mysiam,现在你再看看,默认是innodb类型的。

服务器的配置情况。

上一篇:NHibernate教程(14)--使用视图


下一篇:Activiti-02-activiti api