抛开具体的业务不谈,在纯技术的角度通常的解决方案:第一:成本最低也是最实用的方式:索引优化、sql优化。
第二:上缓存,查询也不一定完全就是数据量大影响的,高访问量请求数据库密集时,影响也很大,用缓存挡在mysql前面,进行流量削锋。第三:分库,把一个数据库,根据业务的耦合度、功能的划分,拆成若干个小的库,每个库只保留共同需要的数据就行了,比如用户表,这通常在每个库中都会有相同的一份。
第四:分表,尤其是水平切分。不过分表之后的弊端也是要考虑的,会导致有些业务对该数据的操作需求实现不了或者很麻烦。实际的做法是,分表的同时,仍然保留原表的数据,两份数据。一份是原表数据或者原表一部分的数据,尤其是主键,这个根据你们的业务需求来定。另一份是对原表进行切分的副本,用这个分开的表来满足某部分业务的查询需求即可。至于按什么样的方式分,看业务特征,比如说我做过一款手机游戏的app,在统计用户的月活跃情况时,我会按月份分。
第五:mysql读写分离,这是在一个库中又从读和写的层面上进行分流,一库,两台服务器,一台只负责读,另一台只负责写。其实本质也是一种负载均衡的实现方式
第六:分布式,把同一份数据分到不同服务器上,这个成本就大了,一般的公司用不到,较难解决的问题是在数据的一致性上。可以使用一些现成的中间件。
等等,不管使用什么技术,一定要考虑好这个技术可能带来的后果尤其弊端是什么。回到最上面说的 ,要想做好这里面每一步则又是一个比较大的问题,比如索引、sql语句的优化,什么时候能用上索引,什么时候用不上,多列索引又是什么情况,一个多列索引很多时候并不是能完全用上所有列的索引,有时候只会用上第一列,那什么情况下能用上,什么情况下用不上,都需要对这些有详细的了解。