在数据量大的事情，往往是数据库最先体现出来瓶颈，这个时候大家往往想到缓存，缓存并不是解决问题的灵丹妙药，甚至会掩盖数据库设计不合理的问题，埋下隐患，在使用缓存之前，应先将数据库本身作用发挥到最大；
1、单表查询慢
条件字段类型合理，建立适合的索引；
如果数据量一定程度，索引也解决不了问题，比如翻页，这种情况下需要结合业务的需要，决定是进行分表还是增加缓存，并在sql上限制这些消耗过大的查询；
2、联表查询慢
2.1、第一种情况，需要呈现关联表的数据但这些数据不做为查询条件。在首次查询语句中不联表查询这些仅需要呈现的字段，而是先通过查询缩小范围，然后用另外一条语句查询需要的内容，在两张表中数据都比较大的情况下，这个方法在实际应用中的效果十分明显；
主表table1
|
t1_id
|
t2_id
|
t1_name
|
t1_time
|
从表table2
Select t1.*,t2.t2_name from table1 t1
Left join table2 t1 on t1.t2_id = t2.t2_id
调整方法
Select * from table1
Select * from table2 where t2_id in (1,2,3)
在通过程序关联；
2.2、第二种情况，关联表的数据而且作为查询条件。最好的办法将该字段冗余，并根据实际场景确定是否需要维护以及维护方法；
主表table1
|
t1_id
|
t2_id
|
t1_name
|
t1_time
|
从表table2
|
t2_id
|
t2_name
|
t2_time
|
t2_level
|
Select t1.*,t2.t2_name from table1 t1
Left join table2 t1 on t1.t2_id = t2.t2_id
Where t2.t2_level = 1
调整方法
主表table1
|
t1_id
|
t2_id
|
t2_level
|
t1_name
|
t1_time
|
从表table2
|
t2_id
|
t2_name
|
t2_time
|
t2_level
|
这里的t2_level需要维护，因为t2_level的变化不可预知，所以在table2的行信息发生变化的时候，就需要去维护，这个时候有些人想到可以不可以用触发器，我的观点是不可以，因为数据库只会是复杂业务的一部分，如果过分依赖数据库，程序中的逻辑就可能不完整，将来在数据量进一步扩大的情况，业务的逻辑将很难扩展，所以数据库我们只拿他作为存储和检索；
3、前两条都做了，还是慢，那就是整体架构的问题了，以后再讲。
总之，在数据库量不大的情况，想怎么玩都可以，一但数量大了，你就要思考业务和数据库的紧密结合了，这就需要设计，并在设计的过程中不断提炼和优化，没有一个完美的思路可以很好的解决这个问题，尤其在需求敏捷的状态下，更能体现一个人的责任心和能力；
