mysql大数据量下访问实践

最近参与了一些用户相关系统的开发，经历了数据库在大数据量下出现的一些问题，记录备忘，也请有经验的牛们指点指点。

目前数据量大概在40亿条左右，最近1周大概增长了50%左右，后面可能会小一些，每天预估在几百到几千W条左右。

功能：

java服务接口接收请求，执行sql操作。

查询：

读操作共有5,6种，group by, max（）比较多，查询数据时间范围在1年左右。但要求尽可能的实时，同时并发量较大，记得出现过一次1分钟内某个查询执行了260W次左右的情况。一般情况下1秒钟有1W条左右的sql在执行，除了1个write，1个update，其他都是查询。

阶段1：

开始时按照1主1从的结构部署，读写都在主库。共分了5个库，每个库上400张表（同一张表）。当单表数据量达到100W条后，读操作出现瓶颈，导致mysql load高，io等待严重。考虑将读操作分离到读库上，来减小主库上的压力。

阶段2：

读操作切到读库上后，当天就出现读库load居高不下，频繁报警等情况。DBA建议可减少调用量来降低mysql压力，经过业务分析后，减少了一些不必要的调用，大概减少了1/10左右的调用量，但并发量还是很大，报警依旧。DBA组建议添加1组读库来分担读压力，应用也进行了相应地调整。

阶段3：

在前两个阶段中还出现了主从不同步的问题，后来采用了对索引进行调整的策略来应对。

1.减少从库上的索引来加快数据同步的速度，有一定的效果，但期间从库数据也重做过。

2.减少主库的索引，一定程度上提高了写操作的性能。

阶段4:

为了提高读库的访问性能，1组从库上了fusion卡，从性能监控比较，安装卡后的库在大致相同的处理性能下，可多承担3-5倍的读操作。

数据还在不断增加，比较担心数据的访问性能，尤其是查询数据的时间段比较大，如果单表数据量增大到500W后...