mysql复杂表优化问题

抛开具体的业务不谈，在纯技术的角度通常的解决方案：第一：成本最低也是最实用的方式：索引优化、sql优化。

第二：上缓存，查询也不一定完全就是数据量大影响的，高访问量请求数据库密集时，影响也很大，用缓存挡在mysql前面，进行流量削锋。第三：分库，把一个数据库，根据业务的耦合度、功能的划分，拆成若干个小的库，每个库只保留共同需要的数据就行了，比如用户表，这通常在每个库中都会有相同的一份。

第四：分表，尤其是水平切分。不过分表之后的弊端也是要考虑的，会导致有些业务对该数据的操作需求实现不了或者很麻烦。实际的做法是，分表的同时，仍然保留原表的数据，两份数据。一份是原表数据或者原表一部分的数据，尤其是主键，这个根据你们的业务需求来定。另一份是对原表进行切分的副本，用这个分开的表来满足某部分业务的查询需求即可。至于按什么样的方式分，看业务特征，比如说我做过一款手机游戏的app，在统计用户的月活跃情况时，我会按月份分。

第五：mysql读写分离，这是在一个库中又从读和写的层面上进行分流，一库，两台服务器，一台只负责读，另一台只负责写。其实本质也是一种负载均衡的实现方式

第六：分布式，把同一份数据分到不同服务器上，这个成本就大了，一般的公司用不到，较难解决的问题是在数据的一致性上。可以使用一些现成的中间件。

等等，不管使用什么技术，一定要考虑好这个技术可能带来的后果尤其弊端是什么。回到最上面说的 ，要想做好这里面每一步则又是一个比较大的问题，比如索引、sql语句的优化，什么时候能用上索引，什么时候用不上，多列索引又是什么情况，一个多列索引很多时候并不是能完全用上所有列的索引，有时候只会用上第一列，那什么情况下能用上，什么情况下用不上，都需要对这些有详细的了解。

http://www.45zq.cn/portal/article/index/id/165.html