笼统回答：用 explain

偷懒：使用缓存，定期更新

具体：要知道几张表，有没有索引，数据量大小等等

反模式，冗余，建缓存表，对那种读占多数的情况很适用。

比如一个 post 有用户 id，如果要找出用户名，要联查用户表，这时候建立一个用户名字段，在早期生成 post 的时候就写进去，这样显示 post 就不用联查 用户表了。

数据一致性通过程序保证，比如改用户名，那就要在其它有用户名字段的地方也要相应修改。

1、在设计之初，考虑数据增长趋势，建立合适的索引。 2、表关联的外键建立索引。 3、建立一些冗余数据，来避免 join 查询

和 @peter 所说的一样

比如两个表 deals(tb_shop_id) 和 tb_shops(wangwang, name.....) 。经常有这种需求，根据 wangwang 去查询deals 数据 一般写法

SELECT deals.*
FROM deals INNER JOIN tb_shops ON deals.tb_shop_id = tb_shops.id
WHERE tb_shops.wangwang='xxxxxx'

但是，如果在设计之初，考虑到这种需求，那么在表 deals上记录 tb_shop_id 和 wangwang，那么就不需要 join 表查询了。 只有在 tb_shops.wangwang 修改的时候同步 deals 表 如下：

SELECT deals.*
FROM deals 
WHERE deals.wangwang = 'xxxxxx'

4、数据库良好的设计，一定要，所见及所得，避免复杂的查询。 比如日志表，xxxx_logs 可能会有百万或千万的数据。那么避免对这个表做任何查询。可以根据需求建立几个小的统计表。 比如，商家每天的消费情况，商家的总消费情况，所有的数据在存入 xxxx_logs 的时候，对应把数据同步到这几个小表中。

商家每日消费情况表tb_shop_day_details，商家总消费情况tb_shops_total_details

比如查看所有商家的总消费情况，只需要查询 tb_shops_total_details 不再需要从 xxxx_logs 临时计算数据，返回。 比如，要查看商家2014-11-11那一天消费的情况，那么也只需要

SELECT *
FROM tb_shop_day_details
WHERE st_date = '2014-11-11'

所有数据所见及所得，那么这种情况就不需要 JOIN 表操作。

5、将多表的数据查询，提前汇总到一个表。在真正需要查询的时候，从该汇总表中查询。

6、读写分离。在主库写，从库读。

7、将多表 join 查询，改成几条简单的 SQL 查询，最后在组合数据。

8、如果觉得上述的太麻烦，使用 solr 吧，但是原理是一样的，将预计要查询的汇总在一个表。

其实多表查询慢，第一、没有建立合适的索引，第二，存在不良的表结构设计。 在系统初期，没有做好设计。导致数据增长不可控，不良的表结构设计，肯定会导致多表查询慢。 要解决多表查询缓慢的问题，从修改表结构开始，一步一步优化，肯定能达到预期的效果。

a million dollar question.

#3 楼 @ibugs 需求天天在换，昨天的 1 对多明天就是多对多，过几天回来又变成 1 对 1. 在系统初期做好设计，这种说法有点不切实际。

现在主要的问题是数据库中的数据太多，主表里就有60多万条数据，加了index，做了view还是非常的慢。 我已经想不到别的办法了。

#6 楼 @jerrym 楼主，60 万数据一点都不多啊，不涉及机密的情况下，能具体说一下吗？

@MrPasserby 产品是开发的死对头。一般遇到这种问题，都会详细的了解需求，确定是否要该表结构。 一般遇到这种频繁修改表结构的需求，至少都会在我这边自动屏蔽。

SO，一个好的产品，很关键。

@jerrym 60W 的数据一点都不多，我们的表经常是上百万，千万的，合适的表结构，恰当的索引，都会大大减少查询的时间。

#6 楼 @jerrym 应该是索引没用好

#6 楼 @jerrym 业务复杂了以后加索引可以根据慢查询记录来做，有针对的来加索引。一般来说正常配置的机器上面，mysql 数据量在千万以下的级别，不会有性能问题，60w 的库完全算不上大，觉得访问慢那基本是在扫表~

建议楼主详细看看关于 mysql 索引的资料，优化的时候多用用 explain，看看查询到底有没有命中索引。